VPN गेटवे को IP फ़ॉरवर्डिंग चाहिए: क्या जाँचें

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

दोनों भूमिकाएँ स्वतंत्र हैं, और दोनों पता फ़ैमिलियाँ भी।

अपने ही पते पर जवाब देना कुछ साबित नहीं करता

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

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

यही बात फ़ॉरवर्डिंग निर्णय के सामने वाले फ़ायरवॉल पर भी लागू होती है, जिसकी यह तय करने की अपनी नीति है कि क्या फ़ॉरवर्ड किया जा सकता है।

हर पता फ़ैमिली अलग-अलग जाँचें

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

sysctl net.ipv4.ip_forward
sysctl -a --pattern 'net.ipv6.conf.(all|default).forwarding'
nft list ruleset | head -n 40

कई डिस्ट्रीब्यूशन में रनटाइम में आप जो मान पढ़ते हैं वह वहाँ किसी सेवा या कॉन्फ़िगरेशन फ़ाइल ने रखा है, इसलिए एक बार के कमांड से किया गया बदलाव रीबूट पर गायब हो सकता है। रनटाइम मान बदलने से पहले वह फ़ाइल खोजें जिसके पास यह सेटिंग है।

फ़ॉरवर्डिंग चार आवश्यकताओं में से एक है

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

क्लाउड प्लेटफ़ॉर्म पाँचवाँ विचार जोड़ते हैं। कुछ इंस्टेंस पर स्रोत और गंतव्य जाँच लागू करते हैं, जिससे फ़ॉरवर्डेड पैकेट गिर जाते हैं, चाहे गेस्ट कर्नेल कैसा भी कॉन्फ़िगर हो। वहाँ प्लेटफ़ॉर्म का अपना नेटवर्किंग दस्तावेज़ ही प्रमाण है, VM के अंदर का sysctl आउटपुट नहीं।

गेटवे से नहीं, क्लाइंट से परीक्षण करें

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

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

अगर पैकेट आते हैं और सेवा फिर उपयोगकर्ता को अस्वीकार कर देती है, तो आप नेटवर्किंग से आगे बढ़ चुके हैं। फ़ॉरवर्डिंग नीति फिर से चौड़ी करने के बजाय एप्लिकेशन प्राधिकरण के साथ आगे बढ़ें।