सर्व्हरचा IP बदलल्यानंतरही SNAT नियम जुनाच पत्ता घेतो

सर्व्हर नवीन पत्त्यावर गेला, क्लायंट अजूनही जोडतात, आणि ते पाठवतात त्यातले काहीही इंटरनेटपर्यंत पोहोचत नाही. हेच विभाजन सूत्र आहे: ऐकणारा सॉकेट आणि पोर्ट फॉरवर्डिंग स्थलांतरात टिकले, त्यामुळे टनेल वर येते, तर फॉरवर्ड केलेल्या पॅकेटवर लागू होणारे स्रोत भाषांतर अजूनही असा पत्ता घेते जो होस्टकडे आता नाही. त्या पुन्हा लिहिलेल्या पॅकेटना उत्तरे आता नसलेल्या मशीनकडे जातात.

जोडणी आणि फॉरवर्डिंग वेगवेगळ्या ठिकाणी अयशस्वी होतात

स्थापना क्लायंटना आधीच माहीत असलेल्या अंतिम बिंदूवर अवलंबून असते: सार्वजनिक पत्ता, त्यासमोरचे पोर्ट फॉरवर्डिंग आणि आतला श्रोता. फॉरवर्ड केलेला रहदारी पॅकेट टनेलमध्ये शिरल्यानंतर घेतल्या जाणाऱ्या दुसऱ्या निर्णयावर अवलंबून असते, जेव्हा होस्ट आपला स्रोत पुन्हा लिहितो जेणेकरून उत्तरांना परतीचा मार्ग सापडेल.

पत्ता बदलल्याने फक्त दुसरा निर्णय मोडतो, आणि म्हणूनच लक्षण "जोडले आहे पण इंटरनेट नाही" असे वाचले जाते. क्लायंटच्या बाजूच्या नेहमीच्या तपासण्या निरोगी का दिसतात हेही यामुळेच: हॅंडशेक पूर्ण होतो, क्लायंटला पत्ता मिळतो, आणि सर्व्हरच्या टनेल पत्त्यावर ping देखील उत्तर देऊ शकतो. बिघाड दुसऱ्या बाजूला असताना क्लायंटवर तास वाया जातात, म्हणून नियमांची तक्ता ही पहिली पाहण्याची जागा आहे.

संपादनापूर्वी नियम आणि त्याचे काउंटर वाचा

काउंटरसह भाषांतर नियमांची यादी करा आणि कॉन्फिगर केलेल्या स्रोताची तुलना होस्टकडे प्रत्यक्षात असलेल्या पत्त्यांशी करा. मृत पत्त्यावर पुन्हा लिहिलेला नियम सहसा आत जाणाऱ्या मार्गावर रहदारी दाखवतो, कारण पॅकेट त्याला पोहोचतात आणि भाषांतरित होतात, आणि परतीच्या मार्गावर काहीही नाही.

sudo iptables -t nat -L POSTROUTING -n -v --line-numbers
ip -4 addr show

तिथे असताना तीन क्षेत्रे तपासा: स्रोत जुळणीतील पूल, नियम एखाद्याचे नाव घेतल्यास एक्झिट इंटरफेस, आणि टनेल-ते-टनेल रहदारी पुन्हा लिहिण्यापासून रोखणारी वगळणी. संपादनादरम्यान ती वगळणी गमावणे सोपे आहे, आणि ती गमावल्यास सहकाऱ्यांमधली रहदारी चालू असल्यासारखी दिसते, पण तिची उत्तरे विचित्र मार्ग घेतात.

काउंटर शून्यावर अडकले असल्यास पॅकेट या नियमापर्यंत कधीच पोहोचत नाहीत आणि पत्ता हा सध्याचा प्रश्न नाही. साखळीत आधीचा स्पर्धात्मक नियम शोधा, जो तेव्हा घडतो जेव्हा कोणी मूळ संपादित करण्याऐवजी बदली जोडतो. एका मिनिटापूर्वी नोंदवलेल्या आउटपुटशी नियम क्रमांकांची तुलना करा. क्रम हा कॉन्फिगरेशनचा भाग आहे, दिखाऊ तपशील नाही.

स्रोत बदला, किंवा त्याचे नाव घेणे थांबवा

होस्टकडे स्थिर पत्ता असल्यास दुसरा जोडण्याऐवजी नियम त्याच्या जागी बदला. नियम क्रमांकाने बदल केल्यास साखळीचा उर्वरित भाग ज्या क्रमावर अवलंबून आहे तो टिकतो.

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 10.151.0.40

पत्ता गतिशीलपणे दिला जात असल्यास कोणत्याही स्रोताचे नाव घेऊ नका आणि कर्नलला एक्झिट इंटरफेसवरून सध्याचा निवडू द्या. हा प्रकार पुढील स्थलांतर संपादनाशिवाय टिकून राहतो, कोणता पत्ता वापरला हे लपवण्याच्या किंमतीवर.

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -o eth0 -j MASQUERADE

IPv4 फॉरवर्डिंग व्यवस्थापित कॉन्फिगरेशनद्वारे अजूनही सक्षम आहे याची खात्री करा, नंतर वितरणाच्या स्वतःच्या यंत्रणेने नियम कायमस्वरूपी करा. फक्त चालू कर्नलमध्ये केलेला बदल पुढील रीबूटसह परत येतो, सहसा अशा देखभाल विंडोमध्ये जी कोणी बदलाशी जोडत नाही.

बदली चुकीच्या पद्धतीने करण्याचे दोन मार्ग

पूलचे भाषांतर सर्व्हरच्या LAN पत्त्याऐवजी त्याच्या टनेल पत्त्यावर केल्यास उत्तरे थेट टनेलमध्ये परत जातात, जिथे ती कधीही न मागितलेल्या क्लायंटकडे मार्गस्थ होतात. जोडणी राउटिंग लूपसारखी अडकते, कारण ती खरोखर लूप आहे.

जुन्यावर दुसरे भाषांतर चढवणे ही दुसरी चूक. पहिला जुळणारा नियम जिंकतो, त्यामुळे जुनी नोंद हटवली जाईपर्यंत पॅकेट हाताळत राहते, आणि नव्या नियमाचे काउंटर शून्यावर राहतात, पण सर्वजण बदलीला दोष देतात. नवीन काही जोडण्यापूर्वी प्रत हटवा. नंतर यादी पुन्हा एकदा वाचा आणि पूलशी नेमका एकच भाषांतर जुळतो याची खात्री करा.

टनेल IPv6 देखील वाहत असल्यास दुसऱ्या स्टॅकवर संपूर्ण आढावा पुन्हा करा. भाषांतर आणि मार्गस्थ प्रीफिक्स नसलेला IPv6 डीफॉल्ट मार्ग तितकाच शांतपणे अयशस्वी होतो, आणि तो विसरणे सोपे आहे कारण त्यावरील सर्व काही सारखेच दिसते.

आंत येणाऱ्या सेवांना उलटे भाषांतर लागते

VPN क्लायंटवरील सेवा बाहेरून पोहोचण्यायोग्य असणे आवश्यक असल्यास तिला गंतव्य भाषांतर लागते, स्रोत भाषांतर नाही: सार्वजनिक पोर्ट आत येण्यापूर्वी क्लायंटच्या टनेल पत्त्यावर पुन्हा लिहिला जातो. नंतर फॉरवर्ड मार्गाला ती रहदारी परवानगी देणारा स्पष्ट नियम लागतो.

sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 10.9.8.2:8080

टनेल स्वतः वाहणाऱ्या पोर्टचे कधीही भाषांतर करू नका, कारण ते पुन्हा लिहिणे सेवा पोहोचण्यायोग्य ठेवणारी जोडणी तोडते. टनेल पोर्ट गंतव्य नियमांपासून पूर्णपणे बाहेर ठेवा. शेवटी दोन्ही टोकांकडून पडताळा: नव्या नियमावर काउंटर, टनेल उपकरणावर एक छोटा कॅप्चर, आणि सार्वजनिक पत्ता तपासण्यापूर्वी टनेलमधील पत्त्यावर एक विनंती.