VPN เชื่อมต่อใหม่แล้ว แต่เซสชันของแอปยังล้มเหลว
การเชื่อมต่อใหม่ฟื้นเส้นทาง ไม่ใช่สถานะของซ็อกเก็ต เปิดคำขอใหม่หนึ่งรายการในขณะที่คำขอเก่ายังค้างอยู่ แล้วคุณจะรู้ว่าอันไหนในสองอันที่ล้มเหลว
อุโมงค์กลับมา ไคลเอนต์บอกว่าเชื่อมต่อแล้ว แต่เบราว์เซอร์ยังหมุนค้างอยู่บนหน้าก่อนการตัดขาด การเชื่อมต่อ VPN ใหม่ฟื้นเส้นทาง แต่ไม่ฟื้นสถานะการเชื่อมต่อที่แอปและฝั่งไกลสะสมไว้บนเส้นทางเก่า สองสิ่งนี้ต้องซ่อมต่างกัน และการสับสนระหว่างกันจะพาคุณกลับไปที่การตั้งค่า VPN โดยไม่มีเหตุผล
การทดสอบเดียวแยกสองสิ่งนี้ออกจากกันอย่างชัดเจน ใช้เวลาสิบวินาที ส่งคำขอใหม่ไปยังปลายทางเดิมในขณะที่คำขอยังค้างอยู่
อะไรอยู่รอดจากการเชื่อมต่อใหม่ และอะไรไม่อยู่รอด
อุโมงค์คือชุดของเส้นทาง กุญแจ และที่อยู่ และการเชื่อมต่อใหม่สามารถฟื้นทั้งสามอย่างได้ ในขณะที่ทุกโฟลว์ที่ตั้งไว้แล้วยังตายอยู่ ระบบปฏิบัติการถือซ็อกเก็ตไว้เพราะแอปขอไว้ และเวลาหมดอายุของซ็อกเก็ตนั้นอาจอยู่ห่างออกไปหลายนาทีหรือหลายชั่วโมง ภายใต้สิ่งนั้น คู่ตรงข้ามลืมโฟลว์ไปแล้ว รายการแปลหมดอายุแล้ว หรือเส้นทางวิ่งผ่านปลายทางที่ไม่เคยเห็นแฮนด์เชกเลย ไม่มีอะไรในลำดับการเชื่อมต่อใหม่ที่เดินผ่านซ็อกเก็ตของแอปและซ่อมมัน
ไคลเอนต์บางตัวเพิ่มฮุกที่ทิ้งการเชื่อมต่อเก่าเมื่อเชื่อมต่อใหม่ และส่วนใหญ่ไม่ทำ พฤติกรรมตรงนี้แตกต่างตามไคลเอนต์ แพลตฟอร์ม และเวอร์ชัน
ฝั่งไกลก็ลืมคุณเช่นกัน
ปลายไกลถือสถานะของตัวเองไว้ ทั้งเซสชัน TLS บล็อกควบคุม TCP และอาจมีรายการแมปที่ผูกที่อยู่และพอร์ตของคุณไว้กับโฟลว์ อุปกรณ์แปลตามเส้นทางอาจปล่อยให้แมปนั้นหมดอายุในช่วงช่องว่าง แม้อุโมงค์จะกลับมาตั้งอย่างรวดเร็ว เมื่อแมปหายไป แพ็กเก็ตก็มาถึงสำหรับโฟลว์ที่เซิร์ฟเวอร์ไม่รู้จักอีกต่อไป และคำตอบอาจเป็นรีเซ็ตที่ไคลเอนต์ไม่เคยแสดง แอปรายงานสิ่งนี้ว่าเป็นการหยุดชะงักไม่ใช่ข้อผิดพลาด เพราะยังคงรอซ็อกเก็ตที่จะไม่ตอบกลับเลย
เวลาหมดอายุเมื่อไม่มีการใช้งานฝั่งเซิร์ฟเวอร์ทำแบบเดียวกันตามตารางของตัวเอง นั่นคือเหตุผลที่เซสชันอาจตายได้โดยไม่มีเหตุการณ์เครือข่ายใดเลย การเชื่อมต่อที่ไม่มีกิจกรรมนานกว่าที่เซิร์ฟเวอร์คาดไว้ได้หายไปแล้วก่อนที่คุณจะสังเกตว่าอุโมงค์ขยับ
คำขอใหม่คือการทดสอบที่แยกสองสิ่งนี้ออก
ส่งคำขอใหม่ไปยังโฮสต์เดียวกันในขณะที่คำขอเก่ายังค้างอยู่ และดูทั้งสองอย่าง ถ้าคำขอใหม่สำเร็จ แสดงว่าอุโมงค์ เส้นทาง และการแปลงชื่อทำงานทั้งหมด และความผิดพลาดจำกัดอยู่ที่โฟลว์เก่า ถ้าคำขอใหม่ล้มเหลวด้วย ปัญหาอยู่ที่เส้นทาง และสถานะเซสชันของแอปเป็นร่องรอยเท็จ
เก็บการบล็อกทราฟฟิกตรงไว้ให้คงที่ระหว่างการทดสอบ คำขอที่สำเร็จผ่านเส้นทางสำรองโดยบังเอิญไม่ได้พิสูจน์อะไรเกี่ยวกับอุโมงค์
ยืนยันด้วยการเชื่อมต่อใหม่ ไม่ใช่การเชื่อมต่อเก่า
คำสั่งด้านล่างแสดงซ็อกเก็ตที่ยังเปิดอยู่ เริ่มคำขอใหม่หนึ่งรายการ และตรวจว่าตารางเซสชันยังมีรายการของโฟลว์อยู่หรือไม่ รันคำสั่งแรกก่อนและหลังการเชื่อมต่อใหม่เพื่อให้เห็นความต่าง เปลี่ยนโฮสต์และพอร์ตเป็นบริการของคุณเอง
ss -tanp | grep -E ':(443|8443)'
curl -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 https://intranet.example.com/
conntrack -L 2>/dev/null | grep 8443
dig +short intranet.example.com
ซ็อกเก็ตที่ตั้งไว้แล้วซึ่งไม่มีทราฟฟิกเคลื่อนไหวคือลายเซ็นที่ต้องหา และคำขอใหม่ที่คืนรหัสสถานะแสดงว่าเส้นทางยังมีชีวิต ตารางการเชื่อมต่อตอบว่ายังมีอะไรแมปโฟลว์อยู่หรือไม่ และนั่นคือส่วนที่ไคลเอนต์มองไม่เห็น คำถามไปยังตัวแปลงชื่อครอบคลุมอีกครึ่งของการโหลดหน้า เพราะความล้มเหลวของชื่อและการเชื่อมต่อที่ค้างดูเหมือนกันในเบราว์เซอร์ เมื่อรวมกัน ผลลัพธ์ทั้งสี่นี้แยกเซสชันเก่าออกจากอุโมงค์ที่พัง
บันทึกเวลาที่ขาดการเชื่อมต่อ เวลาที่เชื่อมต่อใหม่ และความต่างระหว่างคำขอเก่ากับคำขอใหม่ บันทึกนั้นเปลี่ยนข้อร้องเรียนที่คลุมเครือให้เป็นรายงานที่ใครบางคนลงมือทำได้