होम VPN सर्वर के लिए पोर्ट ट्रिगरिंग बनाम पोर्ट फ़ॉरवर्डिंग
ट्रिगरिंग आउटबाउंड ट्रैफ़िक के बाद मैपिंग खोलती है; फ़ॉरवर्डिंग पोर्ट को स्थायी रूप से मैप करती है। होम VPN सर्वर को दूसरा चाहिए, असली लिसनर तक सीमित।
ज़्यादातर होम राउटर में पोर्ट फ़ॉरवर्डिंग और पोर्ट ट्रिगरिंग एक ही मेन्यू में होती हैं, इसलिए उन्हें एक ही काम करने के दो तरीके माना जाता है। फ़ॉरवर्डिंग एक स्थिर नियम है: WAN पोर्ट पर आने वाला इनबाउंड कनेक्शन एक तय अंदरूनी पता और पोर्ट पर अनुवादित होता है, चाहे कुछ और हो रहा हो या न हो। ट्रिगरिंग सशर्त है: राउटर आउटबाउंड ट्रैफ़िक पर नज़र रखता है और मेल खाता कनेक्शन बाहर जाने के बाद ही इनबाउंड मैपिंग खोलता है। VPN सर्वर इंतज़ार करता है कि कोई और पहले जुड़े, इसलिए वही शर्त एकमात्र चीज़ है जिसे वह कभी पूरा नहीं कर सकता।
अलग जीवन-चक्र वाले दो नियम
IPv4 NAT स्थिति रखता है। जब अंदरूनी होस्ट पैकेट बाहर भेजता है, राउटर एक मैपिंग बनाता है ताकि जवाब वापसी का रास्ता खोज सकें; जो इनबाउंड पैकेट किसी मैपिंग से मेल नहीं खाता वह गिरा दिया जाता है, और यही व्यवहार बिना अपडेट वाले डेस्कटॉप को इंटरनेट से बाहर रखता है। फ़ॉरवर्डिंग हाथ से जोड़ी गई स्थायी अनुवाद प्रविष्टि है। ट्रिगरिंग ट्रैफ़िक पैटर्न से पहरा दिया गया अस्थायी छेद है।
व्यावहारिक अंतर समय का है। फ़ॉरवर्डिंग सहेजे जाने के पल से लेकर किसी के हटाने तक मौजूद रहती है। ट्रिगर हुई मैपिंग ट्रिगर चलने के बाद मौजूद रहती है और निष्क्रियता टाइमर पर बंद होती है, जिसे उपभोक्ता हार्डवेयर पर मिनटों में मापा जाता है, या रीबूट पर तुरंत।
अमूर्त रूप में कोई भी अधिक सुरक्षित नहीं है। फ़ॉरवर्डिंग एक पोर्ट लगातार खुला रखती है; ट्रिगर उसे केवल कुछ खास आउटबाउंड ट्रैफ़िक के बाद खोलता है। ऐसी सेवा के लिए जिसे किसी अजनबी से पहला पैकेट स्वीकार करना है, दोनों में से केवल एक ही काम से मेल खाता है।
ट्रिगरिंग सर्वर को क्यों प्रकाशित नहीं करेगी
VPN सर्वर डिज़ाइन से ही निष्क्रिय है। सामने वाला पक्ष, चाहे कैफ़े में लैपटॉप हो या मोबाइल डेटा पर फ़ोन, पहला पैकेट भेजता है, और राउटर के पास उसके लिए कोई मैपिंग नहीं है। अंदर किसी ने ट्रिगर पोर्ट पर ट्रैफ़िक शुरू नहीं किया, इसलिए नियम कभी चलता ही नहीं और हैंडशेक शुरू होने से पहले कनेक्शन मर जाता है।
जहाँ ट्रिगरिंग काम करती दिखती है, वहाँ कुछ और ट्रिगर पोर्ट पर ट्रैफ़िक पैदा कर रहा होता है: LAN पर एक क्लाइंट, कोई मॉनिटरिंग प्रोब, या सर्वर के अपने आउटबाउंड जाँच। तब मैपिंग उसी एक होस्ट के लिए खुलती है और ट्रैफ़िक रुकने पर बंद हो जाती है, इसलिए अगला बाहरी पक्ष फिर विफल होता है जबकि पहली सफलता लॉग में सबूत की तरह पड़ी रहती है।
ट्रिगरिंग आमतौर पर एक-होस्ट भी होती है। कई कार्यान्वयन एक समय में केवल एक अंदरूनी डिवाइस को मैपिंग रखने देते हैं, जो ऐसे सर्वर के लिए बिल्कुल ग़लत है जिसे कई साथियों को जवाब देना चाहिए। यह सुविधा ऐसे ऐप्स के लिए बनी थी जो बाहर नियंत्रण कनेक्शन खोलते हैं और दूसरे पोर्ट पर इनबाउंड डेटा की अपेक्षा करते हैं, और यह अब भी उसी आकार से मेल खाती है।
फ़ॉरवर्डिंग असल में क्या मैप करती है
फ़ॉरवर्डिंग एक अनुवाद प्रविष्टि है: WAN पोर्ट और प्रोटोकॉल से अंदरूनी पता और पोर्ट तक। इसे दूसरे सिरे पर पहले से चल रहा लिसनर चाहिए, और यह चाहिए कि अंदरूनी पता अपनी जगह पर रहे। दूसरी मशीन पर जाने वाली DHCP लीज़ हर टनल को चुपचाप ग़लत होस्ट पर भेज देती है, इसलिए नियम से पहले आरक्षण बनाइए।
| Rule | Opens when | Closes when | Fits a VPN listener |
|---|---|---|---|
| Port forward | Saved, at boot | You delete it | Yes |
| Port trigger | Matching outbound traffic | Idle timeout or reboot | No |
प्रोटोकॉल फ़ॉर्म के संकेत से अधिक मायने रखता है। UDP पर OpenVPN को UDP फ़ॉरवर्डिंग चाहिए, WireGuard को UDP चाहिए, और IPsec डेटा ESP के रूप में आता है, IP प्रोटोकॉल 50, जिसके कोई पोर्ट ही नहीं हैं। केवल TCP या UDP स्वीकार करने वाला फ़ॉरवर्डिंग फ़ॉर्म इसे व्यक्त नहीं कर सकता, इसलिए IPsec को पोर्ट नियम की जगह पासथ्रू या स्थिर एक-से-एक मैपिंग चाहिए।
आपके राउटर के ऊपर की परत
फ़ॉरवर्डिंग केवल आपके अपने अनुवाद को नियंत्रित करती है। अगर WAN पता आपका नहीं है, जो कैरियर-ग्रेड NAT के पीछे का मामला है जहाँ ग्राहक RFC 6598 में बताए अनुसार 100.64.0.0/10 साझा करते हैं, तो इनबाउंड कनेक्शन कभी आपके राउटर तक नहीं पहुँचता क्योंकि प्रदाता ने पहले अनुवाद कर दिया। आपके डिवाइस का कोई नियम उस क्रम को ठीक नहीं कर सकता।
डबल NAT छोटे पैमाने पर वही समस्या है। आपका राउटर ISP राउटर की ओर फ़ॉरवर्ड करता है, जिसके पास मेल खाता नियम नहीं है और वह पैकेट गिरा देता है। या तो बाहरी डिवाइस पर नियम जोड़िए, या बाहरी डिवाइस को ब्रिज मोड में रखिए और अपने डिवाइस को सार्वजनिक पता रखने दीजिए।
इसीलिए परीक्षण बाहर से आना चाहिए। सार्वजनिक पते के ज़रिए उसी LAN से किया गया परीक्षण hairpin NAT समर्थन पर निर्भर करता है और नियम से असंबंधित कारणों से पास या विफल हो सकता है; मोबाइल डेटा पर फ़ोन, या किसी और नेटवर्क पर मित्र, ज़्यादा साफ़ जाँच है।
नियम को सीमित कीजिए, फिर दोनों आधे जाँचिए
एक पोर्ट एक पते पर फ़ॉरवर्ड कीजिए। पहले प्रयास विफल होने पर जोड़ी गई रेंज, इसी तरह प्रबंधन इंटरफ़ेस इंटरनेट पर पहुँचते हैं, और VPN लिसनर को अपने बगल में राउटर का एडमिन पेज प्रकाशित करने की ज़रूरत नहीं है।
जो पहले से उस लिसनर की रक्षा कर रहा था, वह सब रखिए: प्रमाणपत्र या कुंजी पहचान, होस्ट फ़ायरवॉल, मौजूदा पैकेज संस्करण। फ़ॉरवर्डिंग एक पैकेट अंदर आने देती है; प्रमाणीकरण तय करता है कि पैकेट टनल बनेगा या नहीं, और कुछ गड़बड़ होने पर ये दो अलग विफलताएँ हैं।
जाँच के दो आधे हैं। हैंडशेक बाहरी नेटवर्क से पूरा होना चाहिए, और फिर सर्वर के पीछे का निजी संसाधन टनल से जवाब देना चाहिए। फ़ॉरवर्डिंग टनल कनेक्शन को अंदर आने देती है और इससे ज़्यादा कुछ नहीं; 10.8.0.0/24 के लिए रूटिंग और प्राधिकरण दूसरी स्क्रीन पर दूसरा सेटिंग है।
तीन सवालों से फ़ैसला कीजिए
तीन सवाल किसी भी तुलना तालिका से जल्दी चुनाव तय कर देते हैं:
- क्या बाहर से कोई चीज़ पहले पैकेट के रूप में जुड़ती है? तो फ़ॉरवर्डिंग, या कोई रिले इस्तेमाल कीजिए। ट्रिगरिंग उस आउटबाउंड ट्रैफ़िक के बिना नहीं खुल सकती जो कभी होगा ही नहीं।
- क्या छेद को निष्क्रियता समय से ज़्यादा टिकना है? तो फ़ॉरवर्डिंग इस्तेमाल कीजिए, क्योंकि ट्रिगर हुई मैपिंग अपने ही शेड्यूल पर बंद होती है।
- क्या WAN पता प्रकाशित करने के लिए आपका है? अगर नहीं, तो कोई भी नियम संपादित करने से पहले ऊपर की परत ठीक कीजिए।
अगर तीनों का जवाब ना है, जो उस लैपटॉप का मामला है जो खुद किसी व्यावसायिक प्रदाता को डायल करता है, तो दोनों में से कोई नियम ज़रूरी नहीं है। NAT के पीछे का क्लाइंट काम करता है क्योंकि वह खुद स्थिति-धारक मैपिंग बनाता है, और यह आधी रात को पोर्ट फ़ॉरवर्डिंग वाला पन्ना पढ़ने वाले ज़्यादातर लोगों को कवर करता है।