हिरवा आयकॉन, तोच सार्वजनिक IP: VPN ने कोणता मार्ग वगळला

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

क्लायंटने प्रत्यक्षात काय बसवले

टनेल सुरू आहे का असे विचारण्याऐवजी, पॅकेटला खऱ्या गंतव्याकडे कोणता इंटरफेस नेईल असे विचारा. त्या गंतव्यासाठी मार्ग नसलेला टनेल हा असा खाजगी रस्ता आहे ज्यावर कोणीही जात नाही.

ip route get 9.9.9.9
Find-NetRoute -RemoteIPAddress 9.9.9.9
route print -4

पहिला आदेश Linux आणि macOS वर उत्तर देतो, आणि उरलेले दोन Windows मधील समतुल्य आहेत जिथे एक पुरतो. उत्तरात भौतिक अॅडॉप्टरचे नाव असेल, तर टनेल सुरू आहे आणि डीफॉल्ट मार्ग कधीच हलला नाही. टनेल वापरायला हवे अशा गंतव्यासाठी तपासणी पुन्हा करा, कारण दोन तपासण्या, एक दूरची आणि एक सामान्य, कोणती रचना लागू आहे हे सांगतात.

निवडक राउटिंगचे तीन प्रकार

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

grep -nE "redirect-gateway|route-nopull|route " /etc/openvpn/client/*.conf
ip route show table main | head -20

निर्णय घेणाऱ्या सूचनेसाठी प्रोफाइल वाचा, मग त्याने काय निर्माण केले यासाठी तक्ता वाचा. ढकललेली सूचना क्लायंटवर दाबलीही जाऊ शकते, म्हणून सर्व्हरला दोष देण्यापूर्वी प्रोफाइल आणि तक्ता जुळले पाहिजेत.

पलीकडच्या बाजूने स्रोत पत्ता पुन्हा लिहिला पाहिजे

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

sysctl net.ipv4.ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -S | grep MASQUERADE

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

नाव निराकरण स्वतःचा मार्ग घेते

नाव शोधणारी तपासणी स्थानिक नेटवर्कच्या निराकरणकर्त्याकडे गेलेली असताना रहदारी टनेलमधून बाहेर पडू शकते. दिसणारा पत्ता तोच राहतो, तपासण्या नाहीत, आणि तीच तफावत विभाजित DNS रचना निवडते.

resolvectl status | head -20
resolvectl query example.org

कोणत्या सर्व्हरने उत्तर दिले आणि तो टनेलपूर्वीच्या आधाररेषेपेक्षा वेगळा आहे का ते पाहा. विभाजित टनेलमध्ये ही सहसा अशी सेटिंग असते जी लोकांना पत्त्याबद्दल तक्रार करताना बदलायची होती, आणि तीच जी त्यांनी कधीच पाहिली नाही.

मुद्दा निकाली काढणारी चार निरीक्षणे

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

curl -sS https://ifconfig.me/ip
ip route get 9.9.9.9

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