VPN बिना Git अड्किन्छ? OpenSSH ले IPQoS सँग प्याकेटमा चिन्ह लगाउँछ

OpenSSH ले पूर्वनिर्धारित रूपमा आफ्ना प्याकेटमा QoS मानको चिन्ह लगाउँछ। जहाँ मार्गले त्यो चिन्ह फालिदिन्छ, त्यहाँ पुश अड्किन्छ जबसम्म टनेलले प्याकेटको मार्ग परिवर्तन गर्दैन।

अफिसबाट गरिएको क्लोन चल्छ, फोनको हटस्पटबाट त्यही क्लोन चल्छ, तर होटलको नेटवर्कबाट त्यही क्लोन VPN नचलाएसम्म झुन्डिन्छ। SSH ह्यान्डसेक सकिन्छ र पहिलो वास्तविक स्थानान्तरणमा सत्र चुप हुन्छ। क्लाइन्ट कन्फिगरेसनमा थपिएको एउटा लाइनले git र ssh दुवैलाई सँगै निको पार्छ। जब एउटै क्लाइन्ट सेटिङले एकैचोटि धेरै औजार सुधार्छ, त्यो त्रुटि क्लाइन्टले पठाउने कुरामा हुन्छ, जुन लिङ्कबाट पठाउँछ त्यसमा होइन।

लक्षणलाई मार्गको फरकका रूपमा पढ्नुहोस्

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

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

क्लाइन्टले प्रत्येक SSH सकेटमा QoS बाइट लगाउँछ

7.8 देखि हरेक OpenSSH जडानले IP हेडरमा एउटा मान बोक्छ जुन राउटरहरूले ट्राफिकलाई प्राथमिकता दिन प्रयोग गर्न सक्छन्। टर्मिनल सत्रहरूले एउटा मान पाउँछन् र ठूला प्रतिलिपिले अर्को, टाइप गर्ने मान्छेले फाइल स्थानान्तरणभन्दा राम्रो व्यवहार पाउनुपर्छ भन्ने सिद्धान्तमा। अधिकांश नेटवर्कले यो संकेत पूर्ण रूपमा बेवास्ता गर्छन्, त्यसैले यो वर्षौंसम्म कसैको ध्यानमा पर्दैन। थोरै Wi-Fi ड्राइभर, मोबाइल अपरेटर र VPN केन्द्रीकरणकर्ताले यसअनुसार काम गर्छन्, र तिनमध्ये केहीले नराम्रोसँग काम गर्छन्।

जब त्यो मान प्रवाहको बीचमा पुनः लेखिन्छ वा फालिन्छ, जडान असफल हुँदैन, यो अगाडि बढ्न छोड्छ। पुनःपठन बढ्छ, सञ्झ्याल भत्कन्छ, र केहीले त्रुटि नदिएको हुनाले अनुप्रयोगले केही पनि जानकारी दिँदैन। यही मौनताले मानिसहरूले लक्षणलाई असफलता नभई अड्किने भनी वर्णन गर्नुको कारण हो।

पहिले ssh -V प्रयोग गरी क्लाइन्ट संस्करण पुष्टि गर्नुहोस्। 7.8 वा माथिको कुनै पनि संस्करणले यो व्यवहार पूर्वनिर्धारित रूपमा बोक्छ।

यसलाई MTU र DNS बाट छुट्याउने तीन आदेश

कुनै पनि कन्फिगरेसन फाइल सम्पादन गर्नुअघि दुई समान कारणहरू हटाउनुपर्छ। MTU त्रुटिले साना साटासाट पार गर्छ र पहिलो ठूलो प्याकेटमा जम्छ, जबकि नामको त्रुटिले कहिल्यै सत्र बनाउँदैन।

ssh -o IPQoS=none -v [email protected]
ssh -G [email protected] | grep -i ipqos
sudo tcpdump -ni any -vv "tcp port 22"

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

क्याप्चर सर्भरमा नभई ल्यापटपमा गर्नुहोस्, किनकि मान राख्ने पठाउने पक्ष हो र दुवै दिशाले त्यसलाई बदल्न सक्छन्। चल्ने र असफल हुने मार्गलाई एउटै क्याप्चरले तुलना गर्नुहोस्, अनुमान बिना भिन्नता देखिन्छ।

अपवादलाई एउटा फाइलमा राख्नुहोस्, एकपटकमा एउटा होस्ट

अपवाद लागू हुने होस्टको छेउमा हुनुपर्छ, किन छ भनी बताउने टिप्पणीसँगै।

Host gitlab.example.internal
    IPQoS none
    # direct route rewrites the marking; the tunnel route passes it

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

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

नेटवर्क मालिकसँग वृत्त बन्द गर्नुहोस्

खोजलाई चार तथ्यका रूपमा सुम्पनुहोस्: क्लाइन्ट संस्करण, परीक्षण गरिएको मार्ग, प्रयोग भइरहेको VPN क्लाइन्ट, र कुन दिशाले चिन्ह बोकेको थियो। यी चार नै नेटवर्क मालिकलाई व्यवहार पुनःउत्पादन गर्न र त्यो जानाजान गरिएको हो कि होइन भन्ने निर्णय गर्न पर्याप्त छन्।

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

क्लाइन्टमा गरिएको परिवर्तन म्याद भएको अस्थायी उपाय हो। त्यो म्याद टिप्पणीमा लेख्नुहोस्।

सम्बन्धित लेखहरू