VPN ขาดกลางหน้า: คำขอเบื้องหลังยังออกอยู่หรือไม่

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

งานที่หน้าเริ่มโดยไม่ต้องรอคุณ

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

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

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

ทำไมการโหลดหน้าก่อนหน้าจึงไม่ถือเส้นทาง

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

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

นโยบายความล้มเหลวไปลงเอยที่ไหน

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

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

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

การตรวจสอบที่มีการควบคุมด้วยหน้าใช้แล้วทิ้ง

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

curl -sS --max-time 5 -o /dev/null -w '%{http_code} %{remote_ip}\n' https://probe.example.net/ping

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

ในเบราว์เซอร์ แผงเครือข่ายแยกคำถามสองข้อ กรองเป็น Fetch/XHR แล้วอ่านคอลัมน์ผู้เริ่ม: รายการที่เริ่มโดยตัวจับเวลาหรือสคริปต์ โดยไม่มี Navigation บันทึกไว้ก่อนหน้า คือความพยายามเบื้องหลังไม่ใช่การโหลดใหม่ เปรียบเทียบเวลาเริ่มกับช่วงที่อุโมงค์ขาด ถ้ารายการยังค้างอยู่เมื่ออุโมงค์หายไป คำขอกำลังรอเส้นทางที่ไม่มีอยู่แล้ว

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

จะทำอะไรกับคำตอบ

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

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