घरेलू NAT आपके VPN इंटरफ़ेस की रक्षा क्यों नहीं करता
घरेलू राउटर सुरंग आगे भेजता है, पर मेज़बान डिक्रिप्ट किए गए पैकेट का फ़ैसला करता है। श्रोता, भीतरी पथ और प्रवेश नीति को अलग-अलग पढ़ें।
घरेलू राउटर के पीछे बिना पोर्ट फ़ॉरवर्डिंग वाले लैपटॉप अब भी VPN से आने वाले SSH कनेक्शन स्वीकार करते हैं। यह विरोधाभास नहीं है, क्योंकि दो अलग डिवाइस दो अलग पैकेटों का फ़ैसला करते हैं। राउटर एन्क्रिप्टेड परिवहन आगे भेजता है, और मेज़बान तय करता है कि उसके सुरंग इंटरफ़ेस पर पहुँचने वाले डिक्रिप्ट किए गए पैकेट का क्या करना है। इन दोनों फ़ैसलों को अलग रखना ही पूरा अभ्यास है।
राउटर सुरंग आगे भेजता है, मेज़बान पैकेट का फ़ैसला करता है
किसी एक नियम को देखने से पहले दूर के स्रोत से सेवा तक का पथ बनाइए। बाहरी हिस्सा VPN परिवहन है, जिसे राउटर और गेटवे संभालते हैं। भीतरी हिस्सा तब शुरू होता है जब एंडपॉइंट सुरंग की परत हटाता है और मेज़बान को अपने VPN पते पर भेजा गया पैकेट मिलता है।
इन दोनों हिस्सों को मिला दें और राउटर उस फ़ैसले का श्रेय ले लेता है जो मेज़बान करता है। पोर्ट फ़ॉरवर्डिंग पृष्ठ या राउटर लॉग केवल बाहरी बातचीत बताते हैं, और इनमें से कोई नहीं कहता कि मेज़बान कौन-सा डिक्रिप्ट किया गया ट्रैफ़िक स्वीकार करेगा। मेज़बान भीतरी पैकेट पर अपनी प्रवेश नीति लागू करता है, जैसे किसी भी इंटरफ़ेस पर आने वाले पैकेट पर लागू करता है। इसी नीति में एक्सपोज़र का सवाल वास्तव में तय होता है।
वाइल्डकार्ड श्रोता सार्वजनिक सेवा नहीं है
Linux में INADDR_ANY से बाइंड करने का अर्थ हर स्थानीय पता है, इसलिए कोई सेवा ऐसे सुरंग इंटरफ़ेस पर जवाब दे सकती है जिसका उसने कभी नाम नहीं लिया। IP सॉकेट संदर्भ उस बाइंडिंग का वर्णन करता है, और श्रोताओं की सूची से निष्कर्ष निकालने से पहले उसे पढ़ना उचित है। वाइल्डकार्ड प्रविष्टि सॉकेट के बारे में तथ्य है, पहुँच के बारे में दावा नहीं।
नीचे की दो पंक्तियाँ एक ही सेवा के दो अलग बाइंडिंग हैं, और अंतर इस सवाल का पूरा जवाब है कि क्या इंटरफ़ेस मायने रखता है। सबसे पहले पढ़ें कि सॉकेट किस पते पर बैठा है।
ss -lntp "sport = :22"
LISTEN 0 4096 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=812,fd=3))
LISTEN 0 4096 10.8.0.6:22 0.0.0.0:* users:(("sshd",pid=812,fd=4))उस व्यवस्था का नाम लें जो पोर्ट तक पहुँच सकती हो
तीन व्यवस्थाएँ उस इंटरफ़ेस पर पैकेट रखती हैं, और उनके स्वामी अलग हैं। सही का नाम लेना तय करता है कि किसे नीति बदलनी है।
| Arrangement | What reaches the port | Where the decision lives |
|---|---|---|
| Another permitted VPN peer | A packet from the same tunnel subnet | Gateway forwarding policy and host input rules |
| A deliberate public forward | Traffic the gateway publishes on purpose | Gateway service definition |
| A subnet routed behind the gateway | Client traffic from the far side | Gateway route and host input rules |
सार्वजनिक निकास पता दिखाने वाला ब्राउज़र परिणाम तीनों में से किसी के बारे में कुछ नहीं कहता, क्योंकि वह बताता है कि बाहर जाने वाला ट्रैफ़िक कैसे निकलता है, न कि अंदर आने वाले ट्रैफ़िक को क्या अनुमति है। इसके बजाय श्रोता और सेवा लॉग में स्रोत पते से पीछे की ओर काम करें। यदि स्रोत दूसरा सुरंग साथी है, तो गेटवे नीति दिलचस्प दस्तावेज़ है। यदि यह अनुवादित पता है, तो नियम बदलने से पहले अनुवाद खोजें।
सेवा को उसी पथ तक सीमित करें जो आपका इरादा था
यदि SSH केवल प्रबंधन पथ से चाहिए, तो उस पथ को स्रोत श्रेणी और एक इंटरफ़ेस के रूप में लिखें। फिर मेज़बान के प्रवेश नियमों को नेटवर्क नाम के बजाय इंटरफ़ेस, गंतव्य और स्रोत के अनुसार सीमित करें, क्योंकि निजी दिखने वाला नाम किसी भी पते का प्रतिनिधित्व कर सकता है। अगली समस्या सुलझाने वाले के लिए एक मार्ग छोड़ें।
nft add rule inet filter input iifname "tun0" ip saddr 10.8.0.0/24 tcp dport 22 accept
nft list chain inet filter inputजो नियम सुरंग इंटरफ़ेस और प्रबंधन श्रेणी का नाम लेता है, वह इरादा एक ही जगह बताता है। इसकी तुलना Wi-Fi नेटवर्क के लिए लिखे नियम से करें, जो डिक्रिप्ट किए गए सुरंग ट्रैफ़िक के बारे में कुछ नहीं कहता। जब दोनों परतें असहमत हों, तो मेज़बान की नीति वही है जिससे पैकेट मिलता है।
लॉगिन और पैच को ठीक वहीं रहने दें जहाँ वे हैं; किसी पोर्ट तक पहुँचना कभी उसका उपयोग करने की अनुमति के बराबर नहीं था। किसी भी अपरिचित स्रोत के लिए पता परिवार और समय दर्ज करें, और किसी सुविधा या भेद्यता को दोष देने से पहले जाँच करें। जो नियम हर सुरंग साथी को भीतर आने देता है, वह प्रबंधन सबनेट को आने देने वाले से अलग डिज़ाइन है, और कोई लॉग पंक्ति नहीं बताएगी कि किसका इरादा था।
सुधार को एक सफलता और एक अस्वीकृति के साथ स्वीकार करें
दोनों आधे साबित करें: एक स्वीकृत कनेक्शन सफल होता है और एक बहिष्कृत पथ अस्वीकार होता है। अस्वीकृति वह आधा है जिसे लोग छोड़ देते हैं, और यही दिखाता है कि नियम काम कर रहा है, न कि किसी अनुमति देने वाले डिफ़ॉल्ट के साथ खड़ा है। बहिष्कृत पक्ष से परीक्षण करें, इस पर तर्क करने के बजाय।
दोबारा जुड़ने के बाद जोड़ी दोहराएँ, क्योंकि अलग इंटरफ़ेस नाम के साथ लौटने वाली सुरंग पुराने के लिए सीमित नियम को चुपचाप बायपास कर सकती है। जो सीमा मायने रखती है वह वही है जो मेज़बान उन पैकेटों पर लागू करता है जो उसे वास्तव में मिलते हैं।