Git 403 ขณะเชื่อมต่อ VPN: หาว่าใครเป็นผู้ตอบ
403 คือคำตอบ ไม่ใช่คำตัดสินเกี่ยวกับ VPN ระบุว่าองค์ประกอบใดปฏิเสธ แล้วเปรียบเทียบตัวแปรทีละตัวระหว่างเครือข่ายและบันทึกว่าอะไรเปลี่ยนไป
มันทำงานบน Wi-Fi ของออฟฟิศและล้มเหลวบนฮอตสปอตของโทรศัพท์ โดยเชื่อมต่อ VPN ทั้งสองกรณี Git ตอบกลับ 403 และข้อผิดพลาดยาวสามบรรทัด สิ่งที่ชวนให้ทำคือถือว่าฮอตสปอตเป็นสาเหตุแล้วเปลี่ยนการตั้งค่าเครือข่ายจนมีอะไรขยับ คำถามที่มีประโยชน์คือเซิร์ฟเวอร์ใดเป็นผู้ตอบ และก้าวต่อไปที่มีประโยชน์คือการเปรียบเทียบที่เปลี่ยนทีละอย่าง HTTP 403 หมายความว่าเซิร์ฟเวอร์เข้าใจคำขอและปฏิเสธมัน
อ่านสถานะก่อนดูเครือข่าย
403 ไม่ใช่การค้นหาที่ล้มเหลว ไม่ใช่ TCP หมดเวลา และไม่ใช่การจับมือ TLS ที่ไม่เคยเสร็จสิ้น มันคือการตัดสินใจที่ทำโดยบางสิ่งซึ่งวิเคราะห์คำขอของคุณ
จนกว่าคุณจะรู้ว่าอะไรเป็นการตัดสินใจนั้น ทุกการเปลี่ยนเครือข่ายที่คุณลองคือการเดาพร้อมเรื่องเล่าที่ฟังขึ้น
ใครตอบด้วย 403 ได้บ้าง
แอปพลิเคชันของคลังเก็บเป็นเพียงผู้สมัครรายหนึ่ง พร็อกซี เกตเวย์ หรือบริการกรองสามารถอยู่ข้างหน้าและตอบก่อนได้ และไคลเอนต์เห็นสถานะเดียวกันไม่ว่าทางใด เก็บสถานะ หัวข้อที่เกี่ยวข้อง และเนื้อหาข้อผิดพลาดที่ปิดข้อมูลไว้ แล้วเชื่อมโยงกับบันทึกของบริการที่ได้รับอนุญาต URL ระยะไกลและปลายทางที่ไปถึงจริงอาจแตกต่างกันได้จากการตั้งค่า DNS หรือพร็อกซี ดังนั้นตรวจสอบที่อยู่ที่กำหนดค่าไว้และกระบวนการที่ส่งคำขอ
ถ้าการปฏิเสธไม่เคยไปถึงคลังเก็บ บันทึกของมันจะเงียบ และความเงียบนั้นคือหลักฐาน
เปรียบเทียบทีละตัวแปร
การเปรียบเทียบกับฮอตสปอตมีประโยชน์เพราะทำให้ปัญหาชัดขึ้น ไม่ใช่เพราะพิสูจน์สาเหตุ เครือข่ายสองแห่งอาจต่างกันทั้งการกำหนดที่อยู่ ตระกูล IP พร็อกซี การเจรจา TLS และนโยบายขาออกในเวลาเดียวกัน
เปลี่ยนทีละอย่างต่อการทดลองหนึ่งครั้งและบันทึกส่วนที่เหลือ ตารางด้านล่างคือขั้นต่ำที่ฉันจดไว้ขณะทำสิ่งนี้
| Keep constant | Record when it changes |
|---|---|
| Repository, operation and credentials | Resolved address and IP family |
| Git process and configuration | Proxy use and the responding component |
| Intended VPN profile | Actual route and exit seen by the service |
แถวเดียวที่ต่างกันระหว่างการทำงานที่สำเร็จและการทำงานที่ล้มเหลวคือที่ที่ชั่วโมงถัดไปจะไป
วิธีเลี่ยงเป็นหลักฐาน ไม่ใช่คำอธิบาย
การบังคับใช้ตระกูลที่อยู่อีกแบบอาจเปลี่ยนปลายทาง เส้นทาง หรือตัวกลางที่ถูกเลือกจึงอาจเปลี่ยนผลลัพธ์โดยไม่พิสูจน์ว่า IPv6 เข้ากันไม่ได้กับคลังเก็บ เวอร์ชัน TLS ที่เจรจาต่างออกไปคือการสังเกตในหมวดเดียวกัน ไม่มีข้อใดสนับสนุนการปิดการตรวจสอบใบรับรองหรือทำให้การเชื่อมต่ออ่อนแอลง ติดตามนโยบายและบันทึกขององค์ประกอบที่ปฏิเสธไปจนถึงการตัดสินใจจริง แทนที่จะหยุดที่การเปลี่ยนแปลงแรกที่ได้ผล
วิธีเลี่ยงที่คุณอธิบายไม่ได้จะล้มเหลวอีกที่อื่น
เขียนรายงานที่ได้รับการแก้ไข
ให้เจ้าขององค์ประกอบที่ตอบการดำเนินการเดียวกัน สองเส้นทาง และองค์ประกอบที่บอกว่าไม่ ลบหัวข้อการอนุญาต ข้อมูลรับรองที่ฝังไว้ และรายละเอียดคลังเก็บส่วนตัวก่อนแบ่งปันสิ่งใด
รายงานที่มีประโยชน์นั้นสั้น ทำซ้ำได้ และระบุชั้นแทนที่จะระบุอาการ
การตรวจสอบที่ฉันทำตามลำดับ
ยืนยัน URL ระยะไกลและปลายทางที่แก้ไขแล้ว จากนั้นบันทึกสถานะและหัวข้อจากการทำงานที่ล้มเหลว ทำการดำเนินการเดิมซ้ำบนเครือข่ายที่สองและเปรียบเทียบบันทึกทั้งสอง
จากนั้นนำความต่างนั้นไปยังองค์ประกอบที่ตอบ:
- การตั้งค่าพร็อกซีบนไคลเอนต์และบนเครือข่าย
- นโยบายขาออกหรือการกรองข้างหน้าคลังเก็บ
- ขอบเขตของโทเค็นหรือบัญชี รวมถึงการหมดอายุและเงื่อนไข SSO
- สิทธิ์ของคลังเก็บสำหรับตัวตนที่โทเค็นเป็นตัวแทน
ความหมายของสถานะนั้นอยู่ในRFC 9110และควรอ้างถึงเมื่อคุณเขียนรายงาน