किल स्विच कुनै पनि ट्राफिक बग्नु अघि 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, र प्रत्येक अनुप्रयोगको राउटिङले प्रत्येकले जोडिएको टनेल र भाँचिएको ट्राफिक दिन्छ, र प्रत्येकको पहिलो जाँच फरक छ।