VPN जुड़ा है पर फ़ायरवॉल अब भी रोक रहा है: कौन सा है, यह कैसे पता करें

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

पथ को नीति से अलग करें

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

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

पथ एक ही बार में पढ़ें

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

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

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

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

नीति उस परत में पढ़ें जो उत्तर देती है

पथ सही होने पर, मेज़बान से बाहर की ओर नीति में चलें और उस एक परत पर नज़र रखें जिसके काउंटर हिल रहे हैं:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

सुनने वाला सॉकेट नियमों से अलग सवाल का उत्तर देता है। यदि पोर्ट पर कुछ नहीं सुन रहा, तो कर्नेल कनेक्शन से मना कर देता है और कोई इनबाउंड नियम प्रासंगिक नहीं है। यदि सॉकेट मौजूद है और दूर के क्लाइंट से कनेक्शन समय-सीमा पर जाता है, तो पथ पर कहीं गिराहट हो रही है, और नियमों के काउंटर बताते हैं कि वह यहीं हो रही है या नहीं।

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

जब टनल वहीं खत्म हो तो गेटवे का निर्णय पढ़ें

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

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

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

सबसे संकरी परत बदलें, फिर सत्यापित करें

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

उसी परीक्षा से, उसी क्लाइंट से सत्यापित करें, और फिर दोबारा जुड़ने के बाद एक बार और, क्योंकि जो नियम टनल के फिर से बातचीत करने से पहले मेल खाता था वह बाद में मेल खाना बंद कर सकता है:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

इसे बंद करने से पहले:

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