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 फेरि खोल्नुहोस् र पहिले असफल हुने अन्तरालभन्दा धेरै परसम्म सत्र खुला राख्नुहोस्। त्यसपछि स्वीकृत नेटवर्क कन्फिगरेसनमा मार्ग स्थायी बनाउनुहोस्, किनकि एकपटकको आदेश रिबुट योजना होइन र अर्को रिबुटमा समस्या नयाँ रहस्यसहित फर्कनेछ।

असममिति कहिले ठीक हुन्छ

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

टिकाउ उत्तरले दुई मार्ग, दुवै देख्नुपर्ने उपकरण र त्यो सम्भव बनाउने मार्गको नाम लिन्छ। यदि तपाईं उपकरणको नाम लिन सक्नुहुन्न भने, तपाईंले अझै कारण भेट्टाउनुभएको छैन।