VPN सबनेटमध्ये पोर्ट फॉर्वर्डिंगवर SNAT लागू करावे का?

राउटरच्या स्वतःच्या VPN क्लायंटमागे असलेल्या होस्टवर पोर्ट फॉर्वर्ड करणे फायरवॉल समस्येसारखे दिसणाऱ्या पद्धतीने अयशस्वी होते, कारण विनंती स्पष्टपणे पोहोचते। सेवा कनेक्शन नोंदवते, क्लायंट वाट पाहतो, आणि काहीही परत येत नाही। गंतव्य अनुवादाने आपले काम केले; परतीचा पॅकेट हा गमावलेला भाग आहे। राउटरवरील एक निवडक स्रोत-NAT नियम हे दुरुस्त करतो, आणि मनोरंजक भाग म्हणजे तो नियम किती अरुंद असू शकतो हे ठरवणे।

उत्तर वेगळा मार्ग का घेते

पोर्ट फॉर्वर्डिंग पॅकेट कुठे जातो हे पुन्हा लिहिते, कधीही कुठून आले हे नाही। इंटरनेट क्लायंटचा पत्ता संपूर्ण टनेलमध्ये स्रोत फील्डमध्ये राहतो, त्यामुळे दूरची सेवा एका अनोळखी व्यक्तीला पाहते आणि ज्या एकमेव पद्धतीने जाणते त्याच पद्धतीने उत्तर देते: स्वतःच्या डीफॉल्ट गेटवेमार्फत। तो गेटवे दुसऱ्या बाजूचा VPN कॉन्सेंट्रेटर आहे, ज्याला कोणत्याही अनियंत्रित सार्वजनिक पत्त्याकडे परतीचा मार्ग नाही।

टनेल इंटरफेसवर कॅप्चर पाहा आणि विषमता स्पष्ट आहे: विनंती पॅकेट बाहेर जातात, आत काहीही येत नाही। फॉर्वर्ड साखळीने प्रवाहाला परवानगी दिली आणि टनेलने तो वाहून नेला, त्यामुळे ड्रॉप तेव्हा होतो जेव्हा दूरच्या होस्टने आधीच परतीचा मार्ग निवडलेला असतो।

विश्वास ठेवण्याइतका अरुंद स्रोत नियम

दूरचा होस्ट ज्याला उत्तर देतो तो स्रोत राउटरला बनवा। या मांडणीत WAN पत्ता 203.0.113.24 आहे, LAN 192.168.88.0/24 आहे, राउटरचा टनेल पत्ता 172.20.5.1 आहे, आणि सेवा 172.20.5.40:8443 वर उत्तर देते। खालील नियम गंतव्य अनुवादानंतरच्या पॅकेटशी जुळतो, म्हणून तो सार्वजनिकऐवजी भाषांतरित पत्त्याचे नाव घेतो। त्यात काहीही क्लायंटच्या पत्त्यावर अवलंबून नाही, आणि हाच मुद्दा आहे।

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

त्या ओळीतील प्रत्येक जुळणी पुनर्लेखन एका टनेलवरील एका सेवेपुरते स्थानिक ठेवण्यासाठी आहे। इंटरफेस किंवा पोर्ट काढून टाका आणि समस्येला आवश्यक असलेल्यापेक्षा जास्त रहदारी पुन्हा लिहाल, आणि अशा प्रकारे लक्ष्यित दुरुस्ती पुढच्या व्यक्तीसाठी कोडे बनते।

केव्हा सर्वव्यापी मास्करेड प्रामाणिक निवड आहे

राउटर अनेक सेवा त्याच VPN सबनेटमध्ये फॉर्वर्ड करत असेल, तर प्रति-सेवा नियम अशी यादी बनतो जी कोणी सांभाळत नाही। टनेल इंटरफेस सोडणाऱ्या सर्व गोष्टी मास्क करणे सोपे आणि अंदाजयोग्य आहे, या किमतीवर की मूळ क्लायंट दुसऱ्या बाजूच्या प्रत्येक होस्टपासून लपलेला राहतो। तिथल्या लॉग आरोपणासाठी वापरले जात नसतील तेव्हा ते निवडा; वापरले जात असतील तेव्हा अरुंद नियम ठेवा।

दोन्ही पर्याय वेगळ्या पद्धतीनेही अयशस्वी होतात। गहाळ अरुंद नियम एक सेवा तोडतो; खूप जुळणारा रुंद मास्करेड आधीच चालू असलेली रहदारी, राउटरचे स्वतःचे बाहेर जाणारे कनेक्शनसह, शांतपणे पुन्हा लिहू शकतो।

प्रकाशित करण्यापूर्वी काउंटर तपासा

कधीही न जुळणारे नियम पॅकेट मोजण्यापर्यंत कार्यरत नियमांसारखेच दिसतात। कोणताही क्लायंट जोडण्यापूर्वी बाइट काउंटरसह तक्ता पुन्हा वाचा, नंतर LAN नसलेल्या नेटवर्कवरून जोडा आणि पुन्हा वाचा। दोन वाचाच अनुमानाला तथ्यात बदलतात। दुसरा हलल्यानंतरच फॉर्वर्ड प्रकाशित करा।

iptables -t nat -L POSTROUTING -v -n --line-numbers

खऱ्या कनेक्शननंतर स्रोत नियमावर शून्य काउंटर म्हणजे जुळणी चुकीची आहे, सहसा कारण गंतव्य किंवा पोर्ट अनुवादानंतरच्या पॅकेटशी जुळत नाही। काउंटर वाढतो पण क्लायंट अजूनही वेळ संपतो, तर परतीचा मार्ग दुरुस्त झाला आहे आणि दुसरे काहीतरी उत्तर टाकून देत आहे, म्हणून पुढे दुसऱ्या बाजूचे फॉर्वर्ड धोरण पाहा। LANच्या आतून हेअरपिन प्रवेश ही वेगळी समस्या आहे आणि त्याला स्वतःचा नियम हवा, याची अधिक रुंद आवृत्ती नाही।