VPN वर SSH दर मिनिटाला तुटतो? कारण keepalive नाही

SSH जोडले जाते, सुमारे एक मिनिट काम करते, आणि नंतर प्रत्येक वेळी जवळपास त्याच अंतराने गोठते. सामान्य स्पष्टीकरण निष्क्रिय टाइमआउट आहे, म्हणून लोक MTU कमी करतात आणि क्लायंट keepalives सेट करतात. मी ज्या WireGuard लिंकवर काम केले ती हे सर्व आधीच पाहिले होते: लहान टनेल MTU, client-alive सेटिंग्ज, कॉन्फिगर केलेला टनेल keepalive. तुटणे बदल न होता सुरू राहिले. कारण असममित LAN मार्ग निघाले, आणि हा नमुना ओळखण्यासारखा आहे कारण तो टाइमर-आधारित प्रत्येक उपायाला हरवतो.

keepalive सिद्ध करते की तुमचा होस्ट अजूनही पाठवायला तयार आहे. ते कधीही त्यातून जात नसलेला प्रतिसाद स्थिती ठेवणाऱ्या उपकरणाला दाखवू शकत नाही.

दंतकथा: keepalives शांत तुटणे दुरुस्त करतात

SSH keepalives एका कामासाठी आहेत: शांतता मोजणाऱ्या गोष्टीला निष्क्रिय सत्र काढून टाकू न देणे. ते ते चांगले करतात. एका दिशेने पहिला पॅकेट पाहून नंतर कधीही प्रतिसाद न पाहिलेल्या स्थिती-ठेवणाऱ्या उपकरणाचा प्रश्न ते सोडवत नाहीत, कारण क्लायंट पाठवतो ते काहीही प्रतिसाद कोणता इंटरफेस वापरतो हे बदलत नाही.

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

संकेत म्हणजे नियमितता आणि त्या अंतरात सत्र वापरण्यायोग्य राहणे. निष्क्रिय टाइमआउट काहीही घडत नसताना मारतात; हा तुम्ही टाइप करत असताना मारतो.

अतिरिक्त गेटवे प्रत्यक्षात काय करतो

लॅपटॉप आणि VPN गेटवे एकाच LAN वर ठेवा, वेगळा LAN फायरवॉल डीफॉल्ट गेटवे म्हणून ठेवा. लॅपटॉप VPN-कडे जाणारा रहदारी फायरवॉलला पाठवतो, फायरवॉल ती गेटवेकडे पुढे पाठवतो, आणि गेटवेचे प्रतिसाद थेट LAN ओलांडून लॅपटॉपकडे परत येतात. तो दुसरा पाय कधीही फायरवॉलमधून जात नाही, म्हणून त्याचा स्थिती तक्ता अर्धे कनेक्शन ठेवतो.

खालील पत्ते ती व्यवस्था दर्शवतात:

Laptop:             192.168.50.20
LAN firewall:       192.168.50.1
WireGuard gateway:  192.168.50.10
Remote VPN subnet:  10.77.0.0/24

रीडायरेक्ट आणि स्थिती हाताळणी नंतर काम करणाऱ्या हँडशेकचे तात्काळ नाही, नंतर मरणारे कनेक्शन करतात. विलंब म्हणजे स्थिती नोंद जुनी होणे किंवा कडक तपासणी अयशस्वी होणे, म्हणूनच अंतर इतके यांत्रिक दिसते.

यापैकी काहीही क्लायंट कॉन्फिगरेशनमध्ये दिसत नाही, म्हणूनच त्याचा शोध सामान्यतः चुकीच्या फाइलमध्ये सुरू होतो.

एक हेतुपूर्वक मार्ग निवडा

वरील व्यवस्थेसाठी, दूरचे सबनेट थेट VPN गेटवेवर राउट केल्यास अर्धे कनेक्शन निघून जाते:

sudo ip route add 10.77.0.0/24 via 192.168.50.10
ip route get 10.77.0.42

ही उदाहरण पत्ते आहेत. पुढील हॉप तुमच्या LAN वर पोहोचण्यायोग्य असले पाहिजे, प्रीफिक्स हेतू असलेले दूरचे नेटवर्क असले पाहिजे, आणि दुसरा आदेश त्यावर विसंबण्यापूर्वी निकाल दाखवतो. गेटवे तुमच्या सबनेटवर नसल्यास, हा मार्ग तुम्हाला हवा असलेला उपाय नाही.

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

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

दोन्ही टोकांकडून चाचणी करा

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

दुरुस्तीनंतर SSH पुन्हा उघडा आणि पूर्वी अयशस्वी होणाऱ्या अंतराच्या खूप पुढेपर्यंत सत्र उघडे ठेवा. नंतर मंजूर नेटवर्क कॉन्फिगरेशनमध्ये मार्ग कायमचा करा, कारण एकवेळचा आदेश रीबूट योजना नाही आणि पुढील रीबूटला समस्या नव्या कोड्यासह परत येईल.

असममिती कधी ठीक आहे

असममित राउटिंग अनेक नेटवर्कमध्ये सामान्य आहे आणि व्याख्येनुसार तुटलेले नाही. ते समस्या तेव्हा बनते जेव्हा स्थिती ट्रॅकिंग, भाषांतर किंवा धोरण त्यांना न दिसणारा मार्ग पाहण्यावर अवलंबून असते, आणि त्यापैकी प्रत्येकावर वेगळा उपाय आहे. त्याभोवती पुनर्रचना करण्यापूर्वी मधल्या उपकरणाला प्रत्यक्षात काय हवे आहे ते तपासा.

टिकाऊ उत्तर दोन मार्गांची, दोन्ही पाहणे आवश्यक असलेल्या उपकरणाची, आणि ते शक्य करणाऱ्या मार्गाची नावे घेते. तुम्ही उपकरणाचे नाव देऊ शकत नसाल, तर तुम्ही अजून कारण शोधले नाही.