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

यह पुनर्लेखन एट्रिब्यूशन को भी नष्ट करता है। इसके बाद क्लाइंट हर कॉलर को सर्वर के टनल पते के रूप में देखता है, जो प्रति-पता किसी भी दर सीमा को एक ही बाल्टी में डाल देता है और छिपा देता है कि किसने क्या भेजा। अगर एट्रिब्यूशन मायने रखता है, तो कनेक्शन सर्वर पर समाप्त करें या अनुमति का निर्णय वहीं रखें और सेवा जिस हेडर पर भरोसा करती है उसमें पहचान भेजें। इन दो सुधारों में से चुनाव इस पर निर्भर है कि सेवा प्रॉक्सी हेडर पढ़ती है या नहीं।

शर्त तीन: एक पोर्ट या कई, और नाम किसका है

एक पोर्ट पर एक सेवा वह मामला है जहाँ प्रयास में रिवर्स फ़ॉरवर्डिंग जीतती है। आपको एक कमांड, एक खाता और एक फ़ायरवॉल नियम चाहिए, और सफ़ाई का अर्थ सत्र को मारना है। एक ही सार्वजनिक पते पर कई सेवाएँ आपको सर्वर-प्रकाशित आकार की ओर धकेलती हैं, क्योंकि हर रिवर्स फ़ॉरवर्डिंग को अपना सर्वर पोर्ट चाहिए और हर सेवा के साथ समुच्चय बढ़ता है।

नाम इसे और जटिल बनाते हैं। रिवर्स फ़ॉरवर्डिंग ऐसे TCP प्रॉक्सी के पीछे बैठ सकती है जो SNI के अनुसार रूट करता है, जबकि अनुवादित पोर्ट आमतौर पर प्रति सेवा एक पोर्ट होता है। अगर सेवा स्वयं TLS समाप्त करती है और मूल होस्टनाम चाहती है, तो प्रॉक्सी दृष्टिकोण उसे बचाए रखता है और DNAT दृष्टिकोण उसे केवल तब बचाता है जब सेवा उस पोर्ट पर वह नाम स्वीकार करे।

लिख लें कि तीन शर्तों में से किसने आकार तय किया। वरना दूसरी सेवा जोड़ने वाला अगला व्यक्ति कम संदर्भ के साथ वही तुलना फिर खोलेगा।

निर्णय लें, फिर बाहर से परखें

ऐसे नेटवर्क से रास्ता परखें जिसका लैपटॉप तक कोई रूट न हो, और अनुरोध चलते समय सर्वर पर काउंटर देखें। सर्वर से उसके अपने सार्वजनिक पते की ओर परीक्षण यहाँ कुछ सिद्ध नहीं करता, क्योंकि पैकेट स्थानीय रूप से बनता है और कभी आने वाले अनुवाद हुक तक नहीं पहुँचता, इसलिए परीक्षण पास हो सकता है जबकि असली रास्ता टूटा हो।

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

स्थिर रहने वाले काउंटर का अर्थ है कि पैकेट कभी नियम तक नहीं पहुँचा, जो प्रदाता या होस्ट फ़ायरवॉल की ओर इशारा करता है। सेवा के मना करते समय हिलने वाले काउंटर क्लाइंट के अपने फ़ायरवॉल या उस पते की ओर इशारा करते हैं जिस पर सेवा सुनती है। जो टनल पैकेट ले जाती है पर कुछ वापस नहीं करती वह रूट या रिवर्स-पाथ की समस्या है, और इन तीन नतीजों में से किसी को भी क्लाइंट एडाप्टर संपादित करके डीबग नहीं करना चाहिए। कुछ बदलने से पहले लिख लें कि कौन सा काउंटर हिला, क्योंकि अगले परीक्षण को वही आधार रेखा चाहिए।

आकार काम करने लगे तो पोर्ट, स्वामी और निगरानी का तरीका टनल कॉन्फ़िगरेशन के बगल में दर्ज करें। जो पहुँच सुधार केवल किसी के शेल इतिहास में मौजूद है, वह एक रीबूट दूर दोहराई गई घटना है।