Linux वरील VPN टनेल खरोखर सुरू आहे का हे कसे तपासावे

Cron दर दहा मिनिटांनी पूर्णपणे निरोगी VPN पुन्हा सुरू करतो आणि तेच काम मृत VPN आठवडाभर चालू ठेवते. दोन्ही अपयश «सुरू» ही एकच गोष्ट मानण्यातून येतात, जेव्हा ती किमान चार आहे. उपकरण प्रशासकीयदृष्ट्या सक्रिय, योग्य रीतीने रूट केलेले, पूर्णपणे एन्क्रिप्टेड असू शकते आणि तरीही काहीही उपयुक्त वाहत नाही. प्रथम निरीक्षणे वेगळी करा, आणि तपासणी जवळजवळ स्वतःच लिहिली जाईल.

लिंक फ्लॅग उपकरणाचे वर्णन करतात, मार्गाचे नाही

सर्व जी तपासणी कॉपी करतात ती केवळ शून्यांचा हार्डवेअर पत्ता शोधते. ती युक्ती काही ड्रायव्हरमध्ये खरा इंटरफेस प्लेसहोल्डरपासून वेगळा करते आणि बाकीच्यांमध्ये काहीही सिद्ध करत नाही, कारण tun उपकरणाकडे कळवण्यासाठी MAC च नाही. ip -brief link show tun0 त्याऐवजी फ्लॅग देतात: UP म्हणजे प्रशासकाने उपकरण सक्रिय केले, आणि LOWER_UP म्हणजे ड्रायव्हर लिंक वापरण्यायोग्य मानतो. एकत्र वाचल्यास, उपकरण अस्तित्वात आहे आणि प्रशासकीयदृष्ट्या बंद नाही असे ते सांगतात. त्यापैकी कोणीही पॅकेटला जाण्यासाठी जागा आहे असे सांगत नाही.

OpenVPN रूट स्थापित होण्यापूर्वीच त्याचे tun उपकरण तयार करते, त्यामुळे काहीही रूट नसतानाही फ्लॅग परिपूर्ण दिसू शकतात. त्यांना पूर्वअट माना, कधीही उत्तर म्हणून नाही.

पॅकेट कुठे जाईल ते विचारा

रूट शोध फ्लॅग उत्तर देऊ शकत नाहीत अशा प्रश्नाचे उत्तर देतो. ip route get 10.8.0.1 from 10.8.0.2 इंटरफेस, स्रोत पत्ता आणि कर्नेल वापरणारा तक्ता यांची नावे देतो, आणि विभाजित टनेलची तपासणी नेमकी त्याच्याशी करावी लागते. स्रोत पत्त्याशिवाय तुम्ही दुसरे काहीतरी विचारत आहात, आणि धोरण-आधारित रूटिंगमध्ये उत्तर स्रोतानुसार बदलू शकते. ही सर्वात स्वस्त प्रामाणिक चाचणी आहे, कारण ती तुमचा रहदारी वापरणार त्याच नियमांना विचारते.

WireGuard साठी, हँडशेक जोडा. wg show प्रत्येक सहकाऱ्यासाठी शेवटच्या हँडशेकचा वेळ-शिक्का छापतो, आणि पुढे सरकणे थांबलेला शिक्का म्हणजे सहकारी गेला आहे, इंटरफेस फ्लॅग काहीही सांगोत. अलीकडील हँडशेक नसलेला संरचित इंटरफेस घरगुती देखरेखीतील सर्वात सामान्य खोट्या सकारात्मकांपैकी एक आहे.

तक्ता 220 IPsec ची कथा सांगतो

strongSwan रूट स्थापना सक्रिय असताना वाटाघाटी केलेल्या निवडकांसाठी तक्ता 220 मध्ये रूट स्थापित करते. ip route list table 220 म्हणून वाटाघाटी केलेल्याला रूट केलेल्यापासून वेगळे करते: लोड केलेल्या कनेक्शनजवळ रिकामा तक्ता म्हणजे IKE आणि CHILD SA वर आले पण त्यांच्याकडे कोणताही रहदारी वळवली जात नाही. तपासा ip xfrm state त्याच्यासोबत, कारण ते स्थापित सुरक्षा संघटना आणि त्यांचे अंतिम बिंदू सूचीबद्ध करते.

सापळा धोरण हेच लक्ष द्यायचे प्रकरण आहे. ते रूट करण्याऐवजी स्वारस्यपूर्ण रहदारीची वाट पाहते, त्यामुळे काहीतरी टनेल सुरू करेपर्यंत तक्ता रिकामा राहतो.

व्यवस्थापक स्थिती आणि डेमन स्थिती वेगळ्या याद्या आहेत

NetworkManager फक्त त्याच्या मालकीच्या कनेक्शनची यादी करतो. nmcli -t -f NAME,TYPE connection show --active थेट wg-quick किंवा OpenVPN डेमनने सुरू केलेल्या टनेलसाठी काहीही परत देत नाही.

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

पुढील पायरीला तिला आवश्यक असलेल्या चाचणीशी जोडा

UDP पोर्ट पोल करणे तयारीबद्दल काहीही सिद्ध करत नाही, कारण UDP मध्ये हँडशेक नाही आणि nc -u पॅकेट बाहेर पडताच यशस्वी होते. पुढील पायरी खरोखर काय वापरते ते तपासा: फॉरवर्ड केलेल्या पोर्टवर TCP कनेक्शन, टनेलमधील होस्टला विनंती, फक्त तिथेच सुटणारे नाव. प्रतीक्षा कालमर्यादा आणि प्रयत्नसंख्येने मर्यादित करा, आणि ती संपल्यावर मोठ्याने अपयशी व्हा.

क्लायंट हुक देतो तेव्हा हुक पोलिंगपेक्षा बरे. --up आणि --down OpenVPN च्या स्क्रिप्ट इंटरफेसची स्थिती बदलल्यानंतर चालतात, ज्यामुळे शर्यत पूर्णपणे नाहीशी होते, पण त्या डेमनने ठेवलेल्या विशेषाधिकारांसह चालतात. OpenVPN ने user आणि group मार्फत विशेषाधिकार नसलेल्या खात्यात पडल्यास, हुक त्या खात्याप्रमाणे चालतो. मग सिस्टम सेवा पुन्हा सुरू करण्यासाठी sudo लागतो जो नेमक्या त्या आदेशास परवानगी देतो. पुनःप्रयत्न cron लूपऐवजी सेवा व्यवस्थापकाकडे सोपवा: सुरुवात मर्यादेसह मर्यादित रीस्टार्ट धोरण तुटलेले टनेल उघड करते, तर अमर्यादित लूप ते अनिश्चित काळ लपवते.