VPN เชื่อมต่อแล้วแต่บริการหนึ่งล้มเหลว: แยกขั้นตอนให้ชัด

«เชื่อมต่อแล้ว» เป็นข้อเท็จจริงที่ให้ข้อมูลน้อยที่สุดในตั๋ว VPN เพราะบันทึกเพียงว่าสองฝ่ายจบแฮนด์เชกแล้ว แต่ไม่บอกชื่อที่ถูกสอบถาม อินเทอร์เฟซที่แพ็กเก็ตออกไป ขนาดของมัน หรือว่าปลายทางไกลยอมรับหรือไม่ นี่คือเหตุผลที่บริการหนึ่งล้มเหลวได้ในขณะที่แอปอื่นทั้งหมดบนแล็ปท็อปเครื่องเดียวกันยังทำงาน เดินตามขั้นตอนให้ครบและขั้นตอนแรกที่ล้มเหลวจะเป็นผู้ระบุข้อบกพร่อง

เริ่มจากชื่อ ไม่ใช่จากอุโมงค์

แก้ชื่อก่อนจะกำหนดเส้นทาง เพราะคำตอบที่ไม่ดีทำให้ทุกการทดสอบหลังจากนั้นไร้ความหมาย สอบถามชื่อผ่านตัวแก้ไขของระบบและเทียบคำตอบนั้นกับที่อยู่ที่แอปใช้จริง ชื่อส่วนตัวที่ตอบกลับมาเป็นที่อยู่สาธารณะหมายความว่าคำถามไปถึงตัวแก้ไขที่ไม่มีความเกี่ยวข้องใด ๆ ชื่อที่แก้ไม่ได้ก็อยู่ในหมวดเดียวกัน เพียงแต่เสียงดังกว่า

resolvectl query host.internal
getent hosts host.internal

เบราว์เซอร์ที่มีการตั้งค่า DNS ปลอดภัยของตัวเองล้มเหลวตรงนี้ ขณะที่ส่วนอื่นของระบบยังทำงาน นี่คือเหตุผลที่ข้อร้องเรียนเฉพาะเบราว์เซอร์ควรมาอยู่ที่ขั้นตอนนี้ก่อน ก่อนที่ใครจะแตะเส้นทาง เปรียบเทียบทั้งสองคำสั่งไม่ใช่เพียงคำสั่งเดียว เพราะ getent เดินตามเส้นทาง NSS แต่การสอบถามตัวแก้ไขไม่ได้ทำเช่นนั้น

ถามเคอร์เนลว่าเลือกเส้นทางใด

ตารางเส้นทางคือลำดับความสำคัญ และเส้นทางที่เคอร์เนลเลือกไม่ใช่สิ่งที่แผนภาพแสดงเสมอ ถามมันโดยตรงเกี่ยวกับปลายทางที่ต้องการ คำตอบระบุอินเทอร์เฟซ ฮอปถัดไป และที่อยู่ต้นทางที่จะใช้ แพ็กเก็ตอาจออกจากอุโมงค์พร้อมที่อยู่ต้นทางที่ปลายทางไกลปฏิเสธ และรายการที่เฉพาะเจาะจงกว่าในตารางกายภาพอาจส่งมันออกทางอินเทอร์เฟซ Wi-Fi แทน

ip route get 10.20.30.40
ip -brief address show

อ่านฟิลด์ dev via และ src ตามลำดับนั้น เพราะแต่ละตัวตัดข้อสงสัยที่ต่างกันออกไป ขั้นตอนนี้ยังเป็นเจ้าของสถานะที่ไคลเอนต์ติดตั้งไว้ เพราะกฎไฟร์วอลล์และเส้นทางอาจคงอยู่หลังการออกที่ไม่ปกติ นี่คือเหตุผลที่ «ไม่มีอินเทอร์เน็ตหากไม่มีอุโมงค์» และ «ไม่มีอินเทอร์เน็ตเว้นแต่ไคลเอนต์ทำงาน» เป็นตระกูลข้อบกพร่องเดียวกัน ไม่ใช่สองตระกูล

ทดสอบขนาดแพ็กเก็ต

คำตอบเล็กที่กลับมาในขณะที่การถ่ายโอนใหญ่หยุดชะงัก ชี้ไปที่ MTU ของเส้นทางก่อน การทดสอบครั้งเดียวด้วยบิต do-not-fragment ที่ตั้งไว้ ส่งจากภายในอุโมงค์ แยกขั้นตอนนี้ออกจากขั้นอื่น ๆ เพิ่มเพย์โหลดจนกว่าการทดสอบจะล้มเหลว แล้วคุณจะได้ตัวเลขที่มีความหมาย

ping -M do -s 1400 10.20.30.40

การทดสอบเล็กผ่านได้ในขณะที่รายการโฟลเดอร์หรือการอัปโหลดค้าง คือลายเซ็นของขั้นตอนนี้ ข้อร้องเรียนฟังดูเหมือนข้อมูลรับรองหรือกฎไฟร์วอลล์ และไม่ใช่ทั้งสองอย่าง

ตัวเลขนี้เป็นคุณสมบัติของเส้นทางไม่ใช่ของไคลเอนต์ ค่าที่ใช้ได้บนการเชื่อมต่อสำนักงานอาจล้มเหลวบนลิงก์มือถือ เก็บคำสั่งทดสอบไว้กับตั๋ว เพราะคนถัดไปต้องการการวัดเดียวกัน หากเพย์โหลดที่เล็กกว่าผ่านได้ ทางแก้คือ clamp หรือ MTU อุโมงค์ที่ต่ำลง ไม่ใช่รหัสลับใหม่

ทดสอบปลายทางไกล

ทดสอบปลายทางด้วยที่อยู่ของมัน แล้วดูว่ามีอะไรฟังอยู่ที่นั่น การเชื่อมต่อที่ถูกปฏิเสธและการเชื่อมต่อที่ไม่เคยตอบกลับเป็นสิ่งที่พบต่างกัน อย่างแรกบอกว่ามีบางอย่างทำงานอยู่และไม่ได้ให้บริการพอร์ตนั้น อย่างที่สองบอกว่าไม่มีอะไรกลับมา ทั้งสองไม่ใช่ปัญหาไคลเอนต์โดยค่าเริ่มต้น

curl -sv http://10.20.30.41:8080/health
nc -vz -w 3 10.20.30.41 3389
ss -lnt 'sport = :8080'

ไม่มีสิ่งใดที่เข้าถึงได้ผ่านอุโมงค์จะเป็นบริการที่ฟังเฉพาะบน 127.0.0.1 เพราะผู้รับฟังไม่เคยเห็นแพ็กเก็ต เมื่อไฟร์วอลล์ของโฮสต์ไกลอนุญาตซับเน็ตสำนักงานและปฏิเสธพูลของอุโมงค์ ผลลัพธ์ดูเหมือนข้อบกพร่องของไคลเอนต์และไม่ใช่เช่นนั้น Remote Desktop หรือการแชร์ไฟล์ที่พังในขณะที่ทราฟฟิกเว็บยังอยู่ มักจบลงตรงนี้ ไม่ว่าผู้ใช้จะพูดอย่างไร

จับคู่ข้อร้องเรียนกับขั้นตอนเดียว

รายงานส่วนใหญ่จัดอยู่ในหนึ่งในห้ารูปแบบ และแต่ละรูปแบบระบุขั้นตอน ไซต์หนึ่งที่ทำงานผ่านอุโมงค์เท่านั้นคือคำตอบของชื่อหรือนโยบายที่ผูกกับที่อยู่ต้นทาง การอัปเดตล้มเหลวโดยไม่มีอุโมงค์ในขณะที่การท่องเว็บทำงาน คือปัญหาเรื่องชื่อหรือเส้นทางของไคลเอนต์นั้น

การที่ทุกอย่างหยุดเมื่อไคลเอนต์ของผู้ให้บริการเริ่มทำงานคือสถานะที่ติดตั้งไว้ นั่นคือคำถามเรื่องเส้นทางและไฟร์วอลล์ บริการหนึ่งเข้าถึงไม่ได้ในขณะที่ส่วนที่เหลือปกติคือปลายทางไกล การถ่ายโอนค้างหลังผ่านไปไม่กี่วินาทีคือขนาดแพ็กเก็ต จับคู่รูปแบบก่อนรันคำสั่ง เพราะมันกำหนดว่าจะเก็บหลักฐานใดก่อน

บันทึกขั้นตอนที่ทำให้เกิดความล้มเหลวแรกพร้อมผลลัพธ์ของคำสั่ง ตั๋วที่บอกว่าที่อยู่ต้นทางผิดและแนบบรรทัดเส้นทางมาด้วยควรค่าแก่การดำเนินการ ส่วนตั๋วที่รายงานว่า VPN เสียไม่ควร