Git ค้างเมื่อไม่มี VPN? OpenSSH ติดเครื่องหมาย QoS ให้แพ็กเก็ตด้วย IPQoS
OpenSSH ติดเครื่องหมายค่า QoS ให้แพ็กเก็ตของตนโดยปริยาย เมื่อเส้นทางทิ้งเครื่องหมายนั้น push จะค้างจนกว่าอุโมงค์จะเปลี่ยนเส้นทางที่แพ็กเก็ตไป
โคลนจากออฟฟิศใช้งานได้ โคลนเดียวกันผ่านฮอตสปอตของโทรศัพท์ก็ใช้งานได้ และโคลนเดียวกันจากเครือข่ายโรงแรมจะค้างจนกว่าจะเปิด VPN การจับมือ SSH เสร็จสิ้นและเซสชันก็เงียบลงเมื่อมีการถ่ายโอนจริงครั้งแรก การเพิ่มบรรทัดเดียวในคอนฟิกของไคลเอนต์รักษาทั้ง git และ ssh พร้อมกัน เมื่อการตั้งค่าไคลเอนต์เพียงอย่างเดียวซ่อมเครื่องมือหลายตัวพร้อมกัน ข้อบกพร่องจึงอยู่ที่สิ่งที่ไคลเอนต์ส่ง ไม่ใช่ที่ลิงก์ที่ใช้ส่ง
อ่านอาการให้เป็นความต่างของเส้นทาง
อุโมงค์ที่รักษาปัญหาแทบไม่เคยเป็นการซ่อมแซม มันสลับเส้นทาง ผู้ให้บริการ และอุปกรณ์กลางทาง ขณะที่แล็ปท็อปยังผลิตแพ็กเก็ตเดิมทุกประการ ถ้าเส้นทางหนึ่งจัดการส่วนหัวผิดและอีกเส้นทางหนึ่งปล่อยผ่านไปโดยไม่แตะต้อง ความต่างอยู่ที่แนวนโยบายของอุปกรณ์กลางทาง ไม่ใช่ที่ไคลเอนต์ อุโมงค์เป็นเพียงพยาน ไม่ใช่ทางออก
จุดที่เซสชันตายทำให้แคบลงอีก ไม่มีอะไรที่ล้มเหลวในการค้นชื่อหรือในการแลกกุญแจที่มีลักษณะเช่นนี้ เซสชันที่ผ่านการยืนยันตัวตน พิมพ์แบนเนอร์ แล้วแข็งค้างที่การเขียนก้อนใหญ่ครั้งแรกได้พิสูจน์แล้วว่าการกำหนดเส้นทาง ชื่อ และข้อมูลรับรองทำงานทั้งหมด
ไคลเอนต์ประทับไบต์ QoS ลงบนซ็อกเก็ต SSH ทุกตัว
การเชื่อมต่อ OpenSSH ทุกครั้งตั้งแต่ 7.8 เป็นต้นไปพาค่าในส่วนหัว 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 ที่ใช้ และทิศทางใดที่พาเครื่องหมายไป สี่ข้อนี้พอให้เจ้าของเครือข่ายทำซ้ำการปฏิบัติและตัดสินว่าเจตนาหรือไม่
ถ้าข้อยกเว้นไม่รักษาการค้าง ให้ถอดออก การเลี่ยงที่รอดจากการทดลองที่ล้มเหลวจะกลายเป็นตำนาน และคนต่อไปใช้เวลาหนึ่งชั่วโมงพิสูจน์ว่ามันไม่ได้ทำอะไรเลย ถ้ามันรักษาการค้างได้ เส้นทางก็ยังผิดสำหรับเครื่องมืออื่นทุกตัวที่ผ่านมัน และการซ่อมเป็นหน้าที่ของผู้ดูแลอุปกรณ์กลางทาง
การเปลี่ยนแปลงที่ไคลเอนต์เป็นมาตรการชั่วคราวที่มีวันหมดอายุ จดวันหมดอายุนั้นไว้ในคอมเมนต์