किल स्विच कोणताही रहदारी वाहण्यापूर्वी VPN सर्व्हरला अडवतो
किल स्विच कोणता टप्पा अडवतो: एंडपॉइंट शोध, बाहेरील मार्ग, परतीचा मार्ग आणि जुने पीअर अपवाद — अंदाजांऐवजी काउंटरने।
किल स्विच अशा दिशेने अपयशी ठरतात ज्याची लोक अपेक्षा करत नाहीत: ते बोगदा बंद असताना रहदारी अडवण्यासाठी बनवलेले आहेत, आणि बोगदा बांधणारे पॅकेट स्वतः रहदारी आहेत। हाच सर्व दोष। बोगद्यातून बाहेर न जाणारे सर्व टाकून देणारा नियमसंच तो बोगदा उभा करणारा हँडशेकही टाकून देतो, म्हणून क्लायंट लूपमध्ये पुन्हा प्रयत्न करतो आणि त्रुटी पहिल्यांदा तपासल्या जाणाऱ्या टप्प्यावर मारली जाते। फायरवॉल रुंदावण्यापूर्वी तीनपैकी कोणता टप्पा नाकारला जातो ते शोधा: नावाचा शोध, पीअरकडे जाणारे बाहेरील पॅकेट, किंवा परत येणारे उत्तर।
बोगदा आणि त्याची स्वतःची वाहतूक एकमेकांवर कशी अवलंबून आहे
VPN क्लायंट एकच सॉकेट मार्ग सामायिक करणाऱ्या दोन नेटवर्क स्थिती म्हणून वाचा। बोगदा अस्तित्वात येण्यापूर्वी क्लायंट भौतिक अडॅप्टरवर सॉकेट उघडतो आणि एन्क्रिप्टेड फ्रेम पीअरच्या पत्त्या आणि पोर्टवर पाठवतो। त्या देवाणघेवाणीच्या यशानंतरच तो बोगदा उपकरण तयार करतो आणि मार्ग बसवतो। किल स्विच दुसऱ्या स्थितीबद्दलचे धोरण आहे, इतके व्यापक लिहिलेले की दोन्हींना लागू होते।
इंटरफेस-आधारित नियम हे नेहमीचे स्वरूप आहेत: यातून बाहेर जाणारे स्वीकारा tun0 किंवा wg0, उर्वरित आउटपुट मार्ग टाकून द्या। ही रचना क्लायंटच्या स्वतःच्या सर्व्हरशी जोडणीला सूट देत नाही, म्हणून योग्य अंमलबजावणी तो अपवाद स्पष्टपणे जोडते, आणि हाताने नियम लिहिताना तुम्हीही तसे करता। Windows आणि macOS वर प्रत्येक अनुप्रयोगाचे नियम इंटरफेसऐवजी प्रक्रिया जुळवून यातील काही टाळतात, पण बोगदा अस्तित्वात येण्यापूर्वी प्रक्रियेलाही बाहेर पडावे लागते।
तीन टप्पे, ते घडतात त्या क्रमाने
पहिला टप्पा म्हणजे निराकरण। प्रोफाइलने शब्दशः पत्त्याऐवजी होस्टनाव साठवले तर काहीही पाठवण्यापूर्वी क्लायंटला DNS उत्तर हवे। DNS ला बोगद्याच्या निराकरणाकडे वळवणारे प्रोफाइल गतिरोध निर्माण करते: निराकरणकर्ता केवळ त्या बोगद्यातूनच उपलब्ध आहे जो शोध सक्षम करायचा आहे। बोगद्याबाहेर निराकरण करणे, किंवा एंडपॉइंटला पत्त्यावर पिन करणे, ही अस्पष्टता दूर करते।
दुसरा टप्पा बाहेरील पॅकेट आहे, ज्याला या क्रमाने आधी मार्गनिर्देशन आणि नंतर फायरवॉल पार करावे लागते। wireguard-tools WireGuard साठी यातील मार्गनिर्देशनाचा अर्धा भाग सांभाळते: स्वतःचे पॅकेट चिन्हांकित करते आणि आत्ताच बसवलेला डीफॉल्ट मार्ग वगळण्यासाठी धोरण नियम जोडते; wg-quick मॅन्युअल पान तो नियम आणि तो वापरत असलेले तक्ते वर्णन करते। ते मार्गनिर्देशन हाताने पुन्हा बांधा, किंवा दुसऱ्या साधनाला नियम पुन्हा लिहू द्या, आणि चिन्हांकित पॅकेट तयार करायच्या बोगद्यात परत पाठवले जाऊ शकतात।
तिसरा टप्पा परतीचा मार्ग आहे। उत्तर नसलेला हँडशेक बाहेर टाकण्याचा पुरावा नाही; तो सर्व्हरच्या आत येणाऱ्या नियमाशी किंवा मॅपिंग विसरलेल्या NAT उपकरणाशी तितकाच सुसंगत आहे। क्लायंटला स्पर्श करण्यापूर्वी हे वेगळे करा।
| What you see | Stage | Where to look |
|---|---|---|
| The client log repeats a resolve step and no packets appear on the wire | 1, name lookup | Resolver path while the tunnel is down |
| The send counter on the physical adapter stays flat | 2, routing | Peer route and policy rules |
| The send counter rises and a firewall drop counter rises | 2, firewall | Rule order, mark, and interface match |
| Packets leave and nothing comes back | 3, return path | Server input rules, NAT, listening port |
क्लायंट आढळलेले लक्षण नोंदवतात, अपयशी टप्पा नाही, म्हणून तक्ता सहसा लॉगपेक्षा वेगवान असते।
काउंटर लॉगपेक्षा वेगाने निर्णय घेतात
Linux वर, nft list ruleset किंवा iptables -vnL OUTPUT प्रत्येक नियमासाठी पॅकेट काउंटर छापते। एकदा जोडा, अपयशी होऊ द्या, नंतर काउंटर पुन्हा वाचा। ज्या नियमाचा काउंटर हलला तोच हँडशेकने धडकलेला नियम; कुठेच काही हलले नाही तर पॅकेट फायरवॉलपर्यंत पोहोचलेच नाही। नियमसंचाने स्वतःचाच हँडशेक टाकून दिल्याचे मी पाहिले आहे, आणि ते फक्त काउंटरनी सांगितले।
फायरवॉलपर्यंत कधीच पोहोचले नाही आणि होस्टमधून कधीच बाहेर पडले नाही हे वेगळे करण्यासाठी इंटरफेसच निरीक्षण करा। ip -s link show dev wlan0 पाठवलेल्या पॅकेटची माहिती देते, आणि tcpdump -ni wlan0 udp port 51820 फ्रेम दाखवते। क्लायंट पुन्हा प्रयत्न करत असताना ते सपाट राहिले तर बिघाड netfilterच्या वर आहे: गहाळ पीअर मार्ग, अजून नसलेल्या उपकरणाकडे निर्देश करणारा धोरण नियम, किंवा क्लायंट गिळणारी सॉकेट त्रुटी।
अपवाद दस्तऐवजी पत्त्यांवर तपासा, जसे 203.0.113.10, जेणेकरून चूक दुसऱ्याचा होस्ट तपासू शकणार नाही।
जुना एंडपॉइंट अपवाद सर्व्हर बंद पडल्यासारखा वाचला जातो
सर्वात गोंधळात टाकणारी आवृत्ती पीअरचा पत्ता बदलल्यानंतर येते: गतिशील पत्ता सेवेने तो हलवला, होस्ट पुन्हा बांधला गेला, किंवा तुमच्या नेटवर्कचा बाहेर जाणारा पत्ता वेगळा आहे। अपवाद अजूनही जुन्या पत्त्याचे नाव घेतो, म्हणून नव्याकडे जाणारे पॅकेट टाकून देण्याच्या नियमावर पडतात। तेच संरचना काल काम करत होती, म्हणूनच लोक सर्व्हरची चौकशी करून सुरुवात करतात।
फायरवॉल नियमातील होस्टनाव तुमची सुटका करत नाही। nftables मध्ये नियमसंच लोड होताना नाव निराकरण होते, म्हणून त्या क्षणी असलेला पत्ता ते पिन करते आणि शब्दशः पत्त्यासारखे जुने होते। टिकाऊ उपाय म्हणजे एंडपॉइंट बदलल्यावर अपवाद अद्ययावत करणे आणि तो अरुंद ठेवणे: एक पीअर पत्ता, एक वाहतूक पोर्ट। पत्ता बदल सहन करण्याइतकी रुंद श्रेणी असंबंधित रहदारीही बाहेर जाऊ देण्याइतकी रुंद असते।
किल स्विच सर्व्हर होस्टवर चालत असताना
तीच अवलंबित्व दुसऱ्या टोकाला आहे, आणि तिथे ते चुकवणे सोपे आहे। तुमचा VPN सर्व्हर म्हणून काम करणारे यंत्र किल स्विच असलेला डेस्कटॉप क्लायंट किंवा लॅपटॉपवरून कॉपी केलेले फायरवॉल प्रोफाइलही चालवत असेल, तर त्याचे टाकून देण्याचे नियम बोगदे संपवणाऱ्या सेवेला लागू होतात। क्लायंटच्या हँडशेकला उत्तरे टाकून दिली जातात, म्हणून सर्व्हर निरोगी दिसत असताना आणि त्याचा बोगदा इंटरफेस न वापरता पडून असताना प्रत्येक क्लायंट जोडू शकत नाही।
त्या होस्टला टाकून देण्यापूर्वी तीन अरुंद स्वीकृती हव्यात: भौतिक इंटरफेसवर ऐकण्याचा पोर्ट, डिक्रिप्ट केलेल्या रहदारीसाठी बोगदा इंटरफेस, आणि बोगद्यातून क्लायंटने पोहोचायच्या ठिकाणी पाठवणे। स्थापित संच याने वाचा: nft list ruleset, iptables -S, किंवा pfctl -sr काहीही बदलण्यापूर्वी, आणि लक्षात ठेवा की जतन केलेला नियमसंच रीबूटनंतरही टिकतो, म्हणून तिथली चूक तो बनवणाऱ्या प्रक्रियेपेक्षा जास्त काळ टिकते।
यंत्र बंद ठेवणारा पुनर्प्राप्ती क्रम
प्रोफाइलपासून बाहेरच्या दिशेने काम करा। क्लायंट वापरत असलेला पीअर पत्ता आणि पोर्ट वाचा, बोगद्याशिवाय होस्टनाव निराकरण होते याची खात्री करा, नंतर केवळ भौतिक अडॅप्टरवर त्या पत्त्या आणि पोर्टसाठी एक अपवाद जोडा। पुन्हा जोडा आणि पाठवण्याचा काउंटर पाहा; पूर्ण झालेला हँडशेक म्हणजे दुसरा टप्पा दुरुस्त झाल्याचा संकेत।
चाचणी करताना टाकून देण्याचे उर्वरित धोरण त्याच्या जागी ठेवा। निरुपद्रवी तपासणी म्हणजे असंबंधित दस्तऐवजी पत्त्यावर जोडणीचा प्रयत्न करून ती अजूनही वेळ संपून थांबते याची खात्री करणे, जे किल स्विच बंद नसून चालू असल्याचे दाखवते। बोगदा स्थिर झाल्यावर अपवाद घट्ट करा, आणि सोयीसाठी क्लायंट प्रोग्रामला कायमची सर्व-परवानगी ठेवू नका।
बोगदा वर आला तरी अनुप्रयोग अपयशी ठरत असेल, तर उर्वरित टप्पे हा नाही: विभाजित DNS, MTU, आणि प्रत्येक अनुप्रयोगाचे मार्गनिर्देशन यापैकी प्रत्येक जोडलेला बोगदा आणि तुटलेली रहदारी देतो, आणि प्रत्येकाची पहिली तपासणी वेगळी आहे।