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 प्रमाणीकरण करू शकते। चारही पूर्ण झाल्यावर रीबूट काहीही बदलत नाही।