के VPN किल स्विच रिबुट पछि टिक्छ? यसलाई कसरी जाँच्ने

रिबुट गर्नु मानिसहरूले किल स्विच परीक्षण गर्ने सबैभन्दा सामान्य तरिका हो, र त्यो सबैभन्दा धेरै झुट बोल्ने परीक्षण हो। क्लाइन्टको चेकबक्स केवल एउटा प्राथमिकता हो; नेटवर्क स्ट्याक माथि आउने क्षण र टनेल वास्तवमै स्थापित हुने क्षणबीच केही कुराले ब्लक लागू गर्छ कि भन्ने मुख्य कुरा हो। Windows मा त्यो कुरा सामान्यतया Windows Filtering Platform मा एउटा फिल्टर, Linux मा एउटा युनिटले लोड गर्ने नियमसमूह, macOS मा pf एङ्कर, Android मा सिस्टमको आफ्नै सधैं-खुला र लकडाउन झन्डाहरू हुन्। यी व्यवस्थाहरू रिबुटभरि धेरै फरक व्यवहार गर्छन्, र प्लेटफर्म-स्तरका मात्र कसैले साइन इन गर्नुअघि आफ्नो ठाउँमा हुन्छन्।

रिबुटले तीन अलग प्रश्न सोध्छ

प्रश्नलाई विभाजन गर्नुहोस्। पहिलो, बुटको समयमा केही कुराले पढ्ने रूपमा नीति डिस्कमा छ? दोस्रो, त्यो पाठक कुनै पनि ट्राफिक बाहिर जानुअघि चल्छ? तेस्रो, नीतिले तपाईंलाई महत्त्वपूर्ण ट्राफिक ढाक्छ, अर्थात् हरेक प्रक्रिया, दुवै ठेगाना परिवार र DNS। पहिलोमा हो र दोस्रोमा होइन भन्नेले मानिसहरूले रिबुटपछि नटिक्ने किल स्विच भनेर रिपोर्ट गर्ने ठ्याक्कै त्यही असफलता उत्पन्न गर्छ: सुरुमा केही सेकेन्ड ट्राफिक बाहिर भाग्छ, र कोही खोज्न नगएसम्म कसैले याद गर्दैन।

तहहरू अलग राख्नुहोस्। सुरक्षित फायरवाल नियमसमूह, बुटमा सुरु हुने सेवा र क्लाइन्टको प्राथमिकता तीन फरक आयु भएका तीन फरक वस्तु हुन्। प्राथमिकता रिबुटपछि टिक्छ किनभने त्यो कन्फिग फाइलमा रहेको मान हो। नियमहरू प्याकेट रोक्ने एकमात्र कुरा हुन्, र तिनीहरू आफूलाई समातेको कर्नेलसँगै हराउँछन्।

ब्लक पुनर्स्थापित गर्ने वस्तु खोज्नुहोस्

Linux मा netfilter नियम कर्नेलमा बस्छन्। तपाईंले व्यवस्था नगरेसम्म बुटको समयमा कसैले तिनलाई फिर्ता लेख्दैन: iptables-save सँग netfilter-persistent, nftables.service लोड गर्छ /etc/nftables.conf, वा तपाईंको आफ्नै स्क्रिप्ट चलाउने systemd युनिट। के सक्षम छ भनेर जाँच्नुहोस्, तपाईंले के कन्फिगर गरेको थियो भनेर सम्झेको कुरा होइन।

systemctl is-enabled nftables netfilter-persistent 2>/dev/null
sudo nft list ruleset
sudo iptables -S OUTPUT

बुटको केही सेकेन्डपछिको खाली नियमसमूह शीर्षकको प्रश्नको उत्तर हो। Windows मा क्लाइन्ट सेवालाई यो कसरी सुरु हुन्छ भनेर सोध्नुहोस्, त्यसपछि टनेल तल हुँदा प्लेटफर्म फिल्टरको अवस्था डम्प गर्नुहोस्।

Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show state

दोस्रो आदेशले wfpstate.xml हालको डाइरेक्टरीमा लेख्छ। क्लाइन्ट जोडिनुअघि नै अवस्थित ब्लक क्रियाका फिल्टरहरू खोज्नुहोस्। Base Filtering Engine बुटको सुरुमै सुरु हुन्छ र स्थायी झन्डासँग थपिएका फिल्टरहरू पुनर्स्थापित गर्छ, त्यसैले केही किल स्विचहरू कुनै क्लाइन्ट विन्डो अवस्थित हुनुअघि नै ट्राफिक ब्लक गर्छन् र केही गर्दैनन्। macOS मा sudo pfctl -s info ले pf सक्षम छ कि भनेर रिपोर्ट गर्छ, sudo pfctl -s rules ले के लोड भएको छ देखाउँछ, र VPN क्लाइन्टहरू सामान्यतया आफ्ना नियमहरू मुख्य समूहमा होइन, एङ्करमा जोड्छन्। utun3 भनी नाम दिने नियमले अर्को बुटपछि अर्को इन्टरफेसमा सङ्केत गर्न सक्छ, किनभने त्यो नम्बर रनटाइममा दिइन्छ।

नेटवर्क माथि आउने र टनेल माथि आउनेबीचको खाली ठाउँ हेर्नुहोस्

खतरनाक अन्तराल पूरै रिबुट होइन, त्यो खाली ठाउँ हो। इन्टरफेसले एउटा क्षणमा लिज र डिफल्ट रुट पाउँछ, VPN सेवा अर्को क्षणमा सुरु हुन्छ, र टनेल अझ पछि प्रमाणीकरण गर्छ, कहिलेकाहीं प्रयोगकर्ता साइन इन गरेर प्रमाण-पत्र एजेन्ट चलेपछि मात्र। ब्लक अन्तिममा लागू भयो भने खाली ठाउँमा भएको सबै खुला रूपमा बाहिर जान्छ।

systemd होस्टहरूमा अनुमान नगरी क्रम पढ्नुहोस्। VPN र फायरवाल युनिटहरूमा systemctl cat चलाउनुहोस् र After= र Before= को सन्दर्भमा network-pre.target वा network-online.target छ कि भनेर हेर्नुहोस्। network-online.target पछि क्रमबद्ध फायरवाल युनिट इन्टरफेससँग हार्छ; network-pre.target माग गर्ने र त्यसअघि क्रमबद्ध युनिट जित्छ। Windows मा समान प्रश्नहरू सेवाको स्टार्ट प्रकार र त्यसका निर्भरताहरू हुन्, किनभने Manual मा राखिएको सेवाले बुट-समयको प्रक्रिया रोक्न सक्दैन। यदि तपाईंको आवश्यकतामा साइन-इन अघिको ट्राफिक पनि समावेश छ भने, यो यन्त्र-स्तरको व्यवस्थाले मात्र पूरा गर्छ: Always On VPN यन्त्र टनेलले मेसिन प्रमाणपत्रसँग प्रमाणीकरण गर्छ र प्रयोगकर्ता लगइन गर्नुअघि जोडिन्छ, र Microsoft यन्त्र टनेलको कन्फिगरेसन अभिलेख गर्छ प्रयोगकर्ता टनेलबाट अलग। Android अर्को बाटो लिन्छ, सधैं-खुला VPN लागू गर्छ र त्यो बिनाका जडानहरू एप प्रक्रियाबाट होइन, सिस्टमबाट ब्लक गर्छ।

परीक्षण चलाउनुहोस्, त्यसपछि दुई समयरेखा तुलना गर्नुहोस्

चुहिए पनि केही खर्च नहुने गन्तव्यसँग रिबुट गर्नुहोस्, र अवस्था खाली ठाउँपछि होइन, खाली ठाउँकै बेला कैद गर्नुहोस्। सबैभन्दा सफा विधि बुट-समय प्रोब हो: प्लेटफर्मले अनुमति दिएसम्म चाँडो सुरु हुने, डिफल्ट रुट र फायरवाल अवस्था रेकर्ड गर्ने, छोटो टाइमआउटसँग एउटा अनुरोध प्रयास गर्ने र स्थानीय फाइलमा एक लाइन थप्ने oneshot युनिट वा तालिकाबद्ध कार्य। त्यो रेकर्डलाई journalctl -b -u वा सिस्टम लगबाट आएको VPN सेवाको सुरु समयसँग तुलना गर्नुहोस्।

त्यसपछि सामान्य परीक्षण चलाउनुहोस्: टनेल माथि, जडान काट्नुहोस्, सिधा ट्राफिक ब्लक हुन्छ कि हेर्नुहोस्, पुनर्स्थापित गर्नुहोस्। दोस्रोमा उत्तीर्ण र पहिलोमा असफल हुनु सामान्य परिणाम हो, र यसको अर्थ कार्यान्वयन क्लाइन्ट पक्षमा छ, बुटमा होइन, क्लाइन्ट जोडिँदा लागू हुन्छ। मैले अन्तिम पटक अडिट गरेको मेसिनमा ब्लक NetworkManager को डिस्प्याचर स्क्रिप्टबाट आएको थियो: उपस्थित र सही र इन्टरफेस माथि आउनुअघिका सेकेन्डहरूका लागि बेकार। दुवै नतिजा लेख्नुहोस्, किनभने रिबुटमा टिक्नुको अर्थ कुन तह कुन क्षणदेखि टिक्यो भनेर भन्नुभयो भने मात्र हुन्छ।

फर्कने बाटो नतोडी खाली ठाउँ बन्द गर्नुहोस्

बुटमा ब्लक छैन भने दोस्रो क्लाइन्ट नियम थप्नुको सट्टा कार्यान्वयन एक तह तल सार्नुहोस्। नियमसमूह सुरक्षित गर्नुहोस् र नेटवर्क प्रयोगयोग्य हुनुअघि क्रमबद्ध युनिटबाट त्यो लोड गर्नुहोस्, र त्यो युनिटलाई आफैंले संरक्षण गर्नुपर्ने DNS खोज वा नेटवर्क माउन्ट आवश्यक छैन भन्ने सुनिश्चित गर्नुहोस्। दायरा समयजत्तिकै महत्त्वपूर्ण छ: प्रयोगकर्ता ID वा cgroup सँग मिल्ने नियमहरू हरेक सिस्टम डिमनलाई ब्लकबाहिर राख्छन्, र केवल IPv4 हेर्ने समूहले IPv6 र DNS पुग्नयोग्य राख्छ।

आफ्नो लागि फर्कने बाटो छोड्नुहोस्। बुटमा सबै ब्लक गरेर त्यसपछि प्रमाणीकरण गर्न नसक्ने मेसिनमा नेटवर्क नै हुँदैन, र उपाय ब्लक मेटाउनु होइन, प्रमाण वा क्रम मर्मत गर्नु हो। स्थानीय कन्सोलको अभिलेखित प्रक्रिया र टनेललाई साँच्चै चाहिने कुराका लागि साँघुरो, जानाजानी गरिएको अपवाद राख्नुहोस्, जस्तै सर्भरको ठेगाना र टनेल हुनुअघि प्रयोग हुने रिजोल्भर।

यो व्यवस्थामा भरोसा गर्नुअघि चार कुरा क्रमैसँग पुष्टि गर्नुहोस्। नीति बुटले पढ्ने ठाउँमा भण्डारण गरिएको छ। त्यो पाठक इन्टरफेस प्रयोगयोग्य हुनुअघि चल्छ। ब्लकले दुवै ठेगाना परिवार र DNS ढाक्छ। ब्लक सक्रिय हुँदा पनि VPN प्रमाणीकरण गर्न सक्छ। चारै पूरा भएपछि रिबुटले केही बदल्दैन।