आपका LAN VPN क्लाइंट पर चल रही सेवा तक क्यों नहीं पहुँच पाता

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

टूटा टनल नहीं है

दोनों सिरे निजी रेंज पर बैठे हैं, जो सामान्य स्थिति है और ग़लत कॉन्फ़िगरेशन नहीं। 10.8.0.6 जैसा पता टनल के अंदर असली है और कहीं और मौजूद नहीं, इसलिए LAN के पास वहाँ कुछ भेजने की कोई वजह नहीं। रूटिंग को छूने से पहले पुष्टि करें कि सेवा टनल के अंदर पहुँच में है भी या नहीं: क्लाइंट पर ss -ltn दिखाता है कि श्रोता 127.0.0.1, LAN इंटरफ़ेस या टनल पते से बँधा है। सिर्फ़ loopback से बँधा डेमन अपने अलावा किसी को जवाब नहीं देता, और कोई रूट, DNAT या पोर्ट फ़ॉरवर्डिंग इसे नहीं बदलती।

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

रूट का आकार: LAN को बताएँ कि पूल कहाँ है

LAN गेटवे पर एक स्थिर रूट सबसे साफ़ जवाब है जब LAN और टनल पूल एक-दूसरे पर न आएँ। पूल को उस मशीन की ओर मोड़ें जो टनल ख़त्म करती है:

ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12   # Windows, persistent

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

push "route 192.168.1.0 255.255.255.0"

ऐसे सबनेट के लिए जो सर्वर के पीछे नहीं बल्कि एक क्लाइंट के पीछे है, सर्वर को सिस्टम रूट और उस क्लाइंट की फ़ाइल में iroute प्रविष्टि दोनों चाहिए, जो client-config-dir के अधीन होती है। iroute के बिना, OpenVPN जानता है कि प्रीफ़िक्स मौजूद है और उसे कोई अंदाज़ा नहीं कि कौन सा क्लाइंट उसका मालिक है: पैकेट आते हैं और डेमन के पास उन्हें मिलाने के लिए कुछ नहीं होता।

यहाँ वह मिथक है जिसका नाम लेना चाहिए। रूट पते को पहुँच-योग्य बनाता है; वह दूसरी तरफ़ को जवाब देने के लिए तैयार नहीं बनाता। साइट-से-साइट साथी इसके ऊपर एक और परत जोड़ते हैं, क्योंकि दूरस्थ गेटवे सिर्फ़ अपनी नीति में सूचीबद्ध प्रीफ़िक्स के अंदर के स्रोतों को स्वीकार करता है, और घरेलू पूल से आने वाला लैपटॉप उनके अंदर नहीं है।

NAT का आकार: अंदर DNAT, और वह SNAT पंक्ति जिसे सब छोड़ देते हैं

जब आप LAN गेटवे को छू नहीं सकते, या ठीक एक पोर्ट प्रकाशित करना चाहते हैं, VPN होस्ट पर अनुवाद LAN पर किसी भी रूट के बिना काम करता है। पोर्ट प्रकाशित करें, उसे फ़ॉरवर्ड करें, और टनल में जाते रास्ते में स्रोत का अनुवाद करें:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1

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

उपभोक्ता फ़र्मवेयर अपने चेन नाम इस्तेमाल करता है और आपके लिए वह अनुवाद नहीं बनाता। Tomato पर, एक इनबाउंड नियम WANPREROUTING में गिरता है और फिर wanin जैसी फ़िल्टर चेन में, और पूरा दिखने वाला नियम-सेट अब भी हाथ से लिखी POSTROUTING पंक्ति माँगता है। यह फ़र्मवेयर की गड़बड़ नहीं; यह सिर्फ़ इनबाउंड ट्रैफ़िक के लिए लिखा नियम-सेट है।

सही दिखने वाला नियम पैकेट फिर भी क्यों गिराता है

इनमें से ज़्यादातर विफलताएँ उस नियम में नहीं हैं जिसे आप घूर रहे हैं। इस क्रम में चार चीज़ें जाँचें, और पहली जो सही न हो वहीं रुकें:

• चेन का क्रम। iptables -I ऊपर डालता है और -A अंत में जोड़ता है, इसलिए पहले वाला अनुमति देने वाला या रोकने वाला नियम पहले फ़ैसला करता है।
• ग़लत चेन। राउटर के ख़ुद को संबोधित ट्रैफ़िक INPUT से गुज़रता है, और फ़ॉरवर्ड किया गया ट्रैफ़िक उसे कभी नहीं छूता। एक सेवा प्रकाशित करने के लिए दोनों जगह नियम चाहिए हो सकते हैं।
• दिशा फ़्लैग। -i tun0 क्लाइंट से आने वाले ट्रैफ़िक से मेल खाता है और -o tun0 उनकी ओर जाने वाले ट्रैफ़िक से। ग़लत फ़्लैग वाला REJECT वह रोक देता है जो आपने चाहा नहीं था।
• स्रोत प्रतिबंध। एक क्लाइंट पता स्वीकार करने वाला फ़ॉरवर्ड उसी क्लाइंट से काम करता है और हर दूसरे स्रोत को एक शब्द कहे बिना गिरा देता है।

शून्य पैकेट काउंटर वाला नियम रास्ते में है ही नहीं, और काउंटर पढ़ना ग़लत-चेन की समस्या को ग़लत-नियम की समस्या से अलग करने का सबसे तेज़ तरीक़ा है।

स्थानीय फ़ॉरवर्डिंग, जब LAN पर कुछ बदला नहीं जा सकता

SSH स्थानीय फ़ॉरवर्डिंग पूरे सवाल को बग़ल में छोड़ देती है। इसे LAN पर रूट, क्लाइंट की फ़ायरवॉल के सहयोग, और कहीं प्रकाशित पोर्ट की ज़रूरत नहीं:

ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host

फिर सेवा टनल चलाने वाली मशीन के localhost:3000 पर दिखती है, और कहीं नहीं। यही सीमा है: एक वर्कस्टेशन, एक पोर्ट, और अगर कोई उसे दोबारा शुरू न करे तो फ़ॉरवर्डिंग सत्र के साथ मर जाती है। स्टेजिंग डेटाबेस जाँचने वाले एडमिन के लिए यह सही औज़ार है। ऐसे कैमरे या स्कैनर के लिए नहीं जहाँ दूसरे लोगों को पहुँचना है, क्योंकि हर उपयोगकर्ता को अपनी फ़ॉरवर्डिंग चाहिए होगी।

नया नियम जोड़ने से पहले दोनों दिशाएँ जाँचें

अनुवाद निशान छोड़ता है, और उन्हें पढ़ना अनुमान लगाने से बेहतर है। VPN होस्ट पर, conntrack -L दिखाता है कि अनुवाद हुआ ही या नहीं, iptables -t nat -L -n -v दिखाता है कि काउंटर हिले या नहीं, और tcpdump -ni any port 3000 दिखाता है कि कौन सा स्रोत पता सचमुच पहुँचा। क्लाइंट पर, ss -ltn पुष्टि करता है कि श्रोता ऐसे पते पर है जहाँ टनल पहुँच सकती है।

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