फक्त WireGuard द्वारे चालणाऱ्या HTTPS सेवेसाठी loopback वर Dante SOCKS

हा रनबुक प्रॉक्सी-जाणकार अनुप्रयोगाला विद्यमान WireGuard मार्गात प्रवेश देतो, VPN सर्व्हरवर किंवा इंटरनेटवर कोणताही प्रॉक्सी पोर्ट प्रकाशित न करता. SOCKS डेमन अनुप्रयोगाचा इंटरफेस देतो, WireGuard आधीच मंजूर केलेला IP मार्ग देतो, आणि यापैकी कोणीही तुमच्यावतीने वापरकर्त्याचे प्रमाणीकरण करत नाही. खालील प्रत्येक पायरी तपासता येईल असे काहीतरी तयार करते, आणि प्रत्येकाला मागे फिरवण्याचा मार्ग आहे: इन्स्टन्स थांबवा, नियम काढा किंवा अनुप्रयोगाची प्रॉक्सी सेटिंग काढून टाका. येथे काहीही होस्टचा डीफॉल्ट मार्ग बदलत नाही.

उदाहरण गृहीत धरते की Dante 1.4.x विश्वासार्ह Linux वर्कस्टेशनवर समर्पित, व्यवस्थापित इन्स्टन्स म्हणून स्थापित आहे, आणि पॅकेजने दिलेले सेवा खाते व लॉग कॉन्फिगरेशन त्यांच्या जागी ठेवले आहे. वर्कस्टेशन 10.77.0.2 त्याच्या WireGuard इंटरफेसवर धारण करते, त्या टनेलमधून 10.60.0.20:443 पर्यंत पोहोचते, आणि सेवेचे योग्य नाव app.corp.example आहे.

पायरी 1: श्रोता फक्त loopback ला बांधा

नेटवर्क, पद्धत आणि नियम विभाग इन्स्टन्सच्या सक्रिय कॉन्फिगरेशनमध्ये ठेवा आणि उदाहरणातील पत्ते बदला. सर्व सर्व्हर सेटिंग्ज नियम ब्लॉकपूर्वी येतात:

internal: 127.0.0.1 port = 1080
external: 10.77.0.2
external.protocol: ipv4
clientmethod: none
socksmethod: none

client pass {
    from: 127.0.0.1/32 to: 127.0.0.1/32
}

socks pass {
    from: 127.0.0.1/32 to: 10.60.0.20/32 port = 443
    command: connect
    protocol: tcp
}

हा एक तुकडा आहे, पॅकेजच्या वापरकर्ता व लॉग सेटिंग्जचा पर्याय नाही. न वापरलेला स्थानिक पोर्ट निवडा आणि खात्री करा की या समर्पित इन्स्टन्सला इतर श्रोते, अधिक व्यापक पास नियम आणि करार बदलू शकणाऱ्या अपस्ट्रीम साखळी नोंदी नाहीत. जर पूर्वीच्या कॉन्फिगरेशनने socks pass गंतव्य-मर्यादेशिवाय सोडले असेल, तर काहीही तपासण्यापूर्वी ते काढा.

या पायरीचे मागे फिरवणे म्हणजे इन्स्टन्स थांबवणे; तुम्ही ते परत आणत असताना कॉन्फिगरेशन फाइल डिस्कवर राहू शकते.

पायरी 2: एक नाही, दोन नियम लिहा

Dante च्या कॉन्फिगरेशन संदर्भात दोन्ही नियम प्रकारांना वेगवेगळी कामे दिली आहेत. क्लायंट नियम loopback श्रोत्याशी जोडणी स्वीकारतो, आणि त्याचे गंतव्य श्रोत्याचे स्वतःचे पत्ता आहे. SOCKS नियम विनंती केलेली पुढील जोडणी मंजूर होस्ट व पोर्टपर्यंत परवानगी देतो. न जुळणाऱ्या विनंत्या डीफॉल्टने अडवल्या जातात, म्हणूनच गहाळ नियम तुटलेल्या मार्गासारखाच दिसतो.

हे कॉन्फिगरेशन जाणूनबुजून काय करत नाही ते पहा: ते कोणताही SOCKS पासवर्ड मागत नाही. हे विश्वासार्ह स्थानिक होस्टसाठी योग्य आहे, आणि हे वापरकर्ता प्रमाणीकरण नाही. त्या मशीनवरील इतर कोणतीही प्रक्रिया loopback वापरू शकते. दूरच्या अनुप्रयोगाचे स्वतःचे प्रमाणीकरण जागेवर ठेवा, आणि हे अप्रमाणित स्वरूप अविश्वासार्ह स्थानिक वापरकर्त्यांसाठी किंवा LAN कडे पाहणाऱ्या श्रोत्यासाठी पुन्हा वापरू नका.

पायरी 3: योग्य स्रोताकडून मार्ग तपासा

external बाहेर जाणारा स्रोत पत्ता निवडतो; तो WireGuard मार्ग स्थापित करत नाही. उदाहरणातील स्रोत व गंतव्यासाठी फक्त-वाचन शोध:

ip -4 route get 10.60.0.20 from 10.77.0.2

ते Dante च्या प्रत्यक्ष नेटवर्क नावस्थानात चालवा, तुमच्याकडे उघडे असलेल्या कोणत्याही शेलमध्ये नाही. मार्ग, WireGuard सहकाऱ्याची निवड, दूरच्या बाजूची परवानगी आणि परतीचा मार्ग—सर्व त्या स्रोत पत्त्याशी जुळले पाहिजेत. यशस्वी शोध आवश्यक आहे आणि पुरेसा नाही, कारण दूरचे टोक विनंती स्वीकारते का याबद्दल तो काहीही सांगत नाही.

शोध यशस्वी व्हावा म्हणून डीफॉल्ट मार्ग जोडण्याच्या मोहाला तोंड द्या. प्रॉक्सी पोर्ट फक्त या वर्कस्टेशनवर आहे; तो तयार करण्यासाठी होस्टचा डीफॉल्ट मार्ग बदलणे संपूर्ण रचना उलटवते.

पायरी 4: इच्छित ओळखीने तपासा

मालकाने स्थापित कॉन्फिगरेशन मान्य केल्यावर आणि सेवा व्यवस्थापकाद्वारे इन्स्टन्स सुरू केल्यावर, एक दृष्टांत विनंती अशी आहे:

curl --proxy socks5h://127.0.0.1:1080 --noproxy '' https://app.corp.example/

सोबत socks5h, Dante गंतव्य विश्लेषण करतो, पण Dante या वर्कस्टेशनवर चालतो, म्हणून सेटिंग स्वतःहून DNS टनेलच्या दूरच्या टोकाला पाठवत नाही. Dante वापरतो त्या मंजूर रिझोल्व्हरने त्या नावासाठी परवानगी दिलेला पत्ता परत द्यायला हवा. रिकामी no-proxy यादी वारशाने मिळालेल्या अपवादाला SOCKS शांतपणे टाळू देत नाही.

चाचणीत HTTPS होस्टनाव व प्रमाणपत्र मान्यता टिकवून ठेवा, नंतर प्रत्यक्ष श्रोत्याचे निरीक्षण करा आणि कराराचे दोन्ही अर्धे भाग पुष्टी करा: परवानगी दिलेली विनंती यशस्वी होते आणि वगळलेले गंतव्य अयशस्वी होते. असमर्थित फॉरवर्डिंग आदेश नाकारले जातात हेही तपासा, कारण हा तुकडा TCP वर SOCKS CONNECT आदेशाला परवानगी देतो आणि सामान्य UDP किंवा संपूर्ण उपकरणाच्या टनेलसारखे काहीही नाही.

पायरी 5: टनेल पडल्यावर काय होते ते ठरवा

याला उत्पादन म्हणण्यापूर्वी टनेल-हानी आणि इन्स्टन्स पुन्हा सुरू करणे तपासा. WireGuard नंतर Dante सुरू करणारा पर्यवेक्षक fail-closed राउटिंग तयार करत नाही, आणि fail-closed DNS देखील तयार करत नाही; दोन्ही नेटवर्क मालकाद्वारे लागू केले पाहिजेत. टनेल खाली असताना अनुप्रयोग काय करतो ते पहा: स्वच्छ त्रुटी चांगला परिणाम आहे, सार्वजनिक रिझोल्व्हरवर शांतपणे पडणे नाही.

बांधलेला टनेल पत्ता बदलल्यास अद्यतने समन्वयित करा, कारण external त्यावर पिन केलेले आहे. जेव्हा या व्यवस्थेची गरज नसते, तेव्हा हा इन्स्टन्स आणि अनुप्रयोगाची प्रॉक्सी सेटिंग एकत्र निवृत्त करा, आणि WireGuard मार्ग त्याच्या मालकाकडे सोडा.