VPN के बिना Git अटकता है? OpenSSH IPQoS से पैकेट पर निशान लगाता है

दफ़्तर से किया गया क्लोन काम करता है, फ़ोन के हॉटस्पॉट से वही क्लोन काम करता है, और होटल के नेटवर्क से वही क्लोन तब तक लटकता है जब तक 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 क्लाइंट, और किस दिशा ने निशान ले जाया। ये चार नेटवर्क मालिक के लिए बर्ताव दोहराने और यह तय करने के लिए काफ़ी हैं कि वह जान-बूझकर है या नहीं।

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

क्लाइंट में बदलाव समाप्ति तिथि वाला अस्थायी उपाय है। वह तिथि टिप्पणी में लिखें।