VPN क्लायंटवरील सेवेपर्यंत पोहोचणे: रिव्हर्स टनेल की DNAT

कॅरियर NAT मागील लॅपटॉपही सहकाऱ्याला सेवा देऊ शकतो, जर VPN सर्व्हर भेटीचे ठिकाण असेल। तिथे पोहोचण्यासाठी दोन यंत्रणा आहेत: क्लायंट बाहेर डायल करतो आणि सर्व्हरला ऐकणारा पोर्ट ठेवण्यास सांगतो, किंवा सर्व्हर पोर्ट प्रकाशित करतो आणि त्याचे टनेलमध्ये भाषांतर करतो। दोन्ही एकच पोहोचण्याची समस्या सोडवतात आणि अपयश, देखरेख व लॉगिंगमध्ये वेगळे वागतात। तुमच्या सेटअपमध्ये कोणते योग्य आहे हे तीन अटी ठरवतात।

दोन आकार, एक भेटीचे ठिकाण

पहिल्या आकारात क्लायंट बाहेरच्या दिशेने SSH सत्र उघडतो आणि सर्व्हरला निवडलेल्या पोर्टवर ऐकण्यास सांगतो, आणि प्रत्येक कनेक्शन त्या सत्रातून परत पाठवतो। सर्व्हरवर काहीही फॉरवर्ड होत नाही आणि पॅकेट भाषांतर होत नाही, त्यामुळे एकमेव आवश्यकता म्हणजे SSH खाते, अनुमत फॉरवर्डिंग आणि पोर्टसाठी फायरवॉल नियम। सेवा क्लायंटवरील लूपबॅकला बांधलेली राहते, जे सहसा तुम्हाला हवे असते।

ssh -N -R 8081:127.0.0.1:8080 -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 [email protected]

दुसऱ्या आकारात सार्वजनिक पोर्ट सर्व्हरकडे असतो आणि प्रत्येक कनेक्शन क्लायंटच्या टनेल पत्त्याकडे पुन्हा लिहितो। त्यासाठी IP फॉरवर्डिंग सक्षम, आत येताना गंतव्य भाषांतर आणि बाहेर जाताना स्रोत भाषांतर आवश्यक आहे, आणि SSH सत्र नसतानाही ते कार्यरत राहते। पोर्ट सत्राचा नाही तर सर्व्हरचा असतो, आणि हाच गुणधर्म बहुतेक वास्तविक प्रकरणे ठरवतो।

दोन्हीपैकी कोणताही आकार रचनेने अधिक सुरक्षित नाही। दोन्ही एक सेवा पोर्ट सर्व्हरच्या सार्वजनिक पत्त्यापर्यंत पोहोचू शकणाऱ्या प्रत्येकासाठी उघडतात, आणि दोन्ही अजूनही सेवेच्या स्वतःच्या प्रमाणीकरणावर अवलंबून आहेत।

अट एक: पोर्ट सत्रापेक्षा जास्त जगावा लागतो का

रिव्हर्स फॉरवर्डिंग ते तयार करणाऱ्या SSH सत्राइतकेच जगते। दुवा तुटल्यावर ऐकणारा नाहीसा होतो आणि सहकारी हळू मार्गाऐवजी नाकारलेले कनेक्शन पाहतो। systemd युनिट आणि रीस्टार्ट धोरणासह आदेशाची देखरेख हे सोडवते, आणि ExitOnForwardFailure=yes अयशस्वी बाइंड तात्काळ दृश्यमान करते, फॉरवर्डिंगशिवाय चालू असलेले सत्र सोडण्याऐवजी।

भाषांतरित पोर्ट नियम जतन केले तर रीबूट टिकतो, पण क्लायंटने तोच टनेल पत्ता राखण्यावर अवलंबून असतो। पुन्हा जोडल्यानंतर लॅपटॉपला वेगळा पत्ता देणारा गतिशील पूल नियम शांतपणे कुठेच निर्देशित करत नाही। आधी टनेल पत्ता राखून ठेवा, नंतर नियम लिहा, आणि दोन्हींना एकच बदल माना।

सेवेला रात्री तीन वाजता कोणीही न पाहता उत्तर द्यावे लागत असेल, तर सर्व्हरने प्रकाशित केलेल्या पोर्टच्या आकारात कमी हलणारे भाग असतात, कारण चालू ठेवावा लागणारा एकमेव प्रक्रिया टनेल स्वतः आहे।

अट दोन: फायरवॉल आणि लॉग कोणाचे

रिव्हर्स आकार सर्व धोरण दोन ठिकाणी ठेवतो। sshd AllowTcpForwarding द्वारे दूरस्थ फॉरवर्डिंगला अजिबात परवानगी आहे का हे ठरवतो, आणि GatewayPorts ऐकणारा लूपबॅकशी बांधला जातो की प्रत्येक पत्त्याशी हे ठरवतो। डीफॉल्ट no असताना सर्व्हरबाहेरील सहकारी फॉरवर्डिंग यशस्वी झाले तरी पोर्टपर्यंत पोहोचू शकत नाही, आणि ते तुटलेल्या टनेलसारखे दिसते, प्रत्यक्षात तो बाइंड पत्ता असतो।

sudo ss -ltn '( sport = :8081 )'
sudo grep -E '^(GatewayPorts|AllowTcpForwarding)' /etc/ssh/sshd_config

भाषांतरित आकाराला फॉरवर्डिंग सक्षम आणि दोन नियम लागतात, आणि दुसरा नियम हाच बहुतेक पद्धती चुकतात तो भाग। स्रोत भाषांतर conntrack च्या DNAT स्थितीपुरते मर्यादित करणे म्हणजे गंतव्य नियमाने तयार केलेली कनेक्शनच पुन्हा लिहिली जातात, सर्व्हर टनेलमध्ये पाठवणारे प्रत्येक पॅकेट नाही।

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8081 -j DNAT --to-destination 10.88.0.6:8080
sudo iptables -t nat -A POSTROUTING -o tun0 -m conntrack --ctstate DNAT -j SNAT --to-source 10.88.0.1

ते पुनर्लेखन श्रेयही नष्ट करते। त्यानंतर क्लायंट प्रत्येक कॉलरला सर्व्हरचा टनेल पत्ता म्हणून पाहतो, ज्यामुळे प्रत्येक पत्त्यासाठीची गती मर्यादा एका बादलीत येते आणि कोणी काय पाठवले हे लपते। श्रेय महत्त्वाचे असेल तर कनेक्शन सर्व्हरवर संपवा किंवा परवानगीचा निर्णय तिथेच ठेवा आणि सेवा विश्वास ठेवते त्या हेडरमध्ये ओळख द्या। या दोन दुरुस्तींपैकी निवड सेवा प्रॉक्सी हेडर वाचते की नाही यावर अवलंबून आहे।

अट तीन: एक पोर्ट की अनेक, आणि नाव कोणाचे

एका पोर्टवर एक सेवा हे असे प्रकरण आहे जिथे प्रयत्नात रिव्हर्स फॉरवर्डिंग जिंकते। एक आदेश, एक खाते आणि एक फायरवॉल नियम लागतो, आणि स्वच्छता म्हणजे सत्र मारणे। एकाच सार्वजनिक पत्त्यावर अनेक सेवा तुम्हाला सर्व्हर-प्रकाशित आकाराकडे ढकलतात, कारण प्रत्येक रिव्हर्स फॉरवर्डिंगला स्वतःचा सर्व्हर पोर्ट लागतो आणि प्रत्येक सेवेबरोबर संच वाढतो।

नावे हे अधिक क्लिष्ट करतात। SNI नुसार राउट करणाऱ्या TCP प्रॉक्सीमागे रिव्हर्स फॉरवर्डिंग असू शकते, तर भाषांतरित पोर्ट सहसा प्रति सेवा एक पोर्ट असतो। सेवा स्वतः TLS संपवत असेल आणि मूळ होस्टनाव आवश्यक असेल, तर प्रॉक्सी दृष्टिकोन ते जपतो, आणि DNAT दृष्टिकोन ते फक्त तेव्हाच जपतो जेव्हा सेवा त्या पोर्टवर ते नाव स्वीकारते।

तीन अटींपैकी कोणी आकार ठरवला ते लिहून ठेवा। नाहीतर दुसरी सेवा जोडणारी पुढील व्यक्ती कमी संदर्भात तीच तुलना पुन्हा उघडेल।

निर्णय घ्या, मग बाहेरून तपासा

लॅपटॉपपर्यंत कोणताही मार्ग नसलेल्या नेटवर्कमधून मार्ग तपासा, आणि विनंती चालू असताना सर्व्हरवरील काउंटर पाहा। सर्व्हरवरून त्याच्या स्वतःच्या सार्वजनिक पत्त्याकडे तपासणे इथे काहीही सिद्ध करत नाही, कारण पॅकेट स्थानिक पातळीवर तयार होते आणि येणाऱ्या भाषांतर हुकपर्यंत कधीही पोहोचत नाही, त्यामुळे खरा मार्ग तुटलेला असतानाही चाचणी उत्तीर्ण होऊ शकते।

sudo iptables -t nat -L PREROUTING -n -v
sudo tcpdump -ni any 'tcp port 8081' -c 20

स्थिर राहणारे काउंटर म्हणजे पॅकेट कधीही नियमापर्यंत पोहोचले नाही, जे प्रदाता किंवा होस्ट फायरवॉलकडे निर्देश करते। सेवा नाकारत असताना हलणारे काउंटर क्लायंटच्या स्वतःच्या फायरवॉलकडे किंवा सेवा ज्या पत्त्यावर ऐकते त्याकडे निर्देश करतात। पॅकेट वाहून नेणारे पण काहीही परत न करणारे टनेल ही मार्ग किंवा रिव्हर्स-पाथ समस्या आहे, आणि या तीन निष्कर्षांपैकी कोणालाही क्लायंट अडॅप्टर संपादित करून डीबग करू नये। काहीही बदलण्यापूर्वी कोणता काउंटर हलला ते लिहा, कारण पुढील चाचणीला ती आधाररेषा लागते।

आकार काम करू लागल्यावर पोर्ट, मालक आणि देखरेख पद्धत टनेल कॉन्फिगरेशनजवळ नोंदवा। फक्त कोणाच्या शेल इतिहासात असलेली पोहोच दुरुस्ती एका रीबूटइतक्या अंतरावर असलेली पुनरावृत्ती घटना आहे।