ทำไมบางเว็บไซต์จึงล้มเหลวเฉพาะเมื่อเปิด VPN?

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

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

ให้ข้อความข้อผิดพลาดเป็นตัวเลือกสาขา

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

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

เว็บที่ตอบกลับยังไม่ได้พิสูจน์ว่าอุโมงค์เสีย

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

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

เมื่อเฉพาะการถ่ายโอนขนาดใหญ่ค้าง ให้ดูขนาดแพ็กเก็ต

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

ทดสอบสมมติฐานนั้นด้วยการไล่ขนาดแทนการ ping ครั้งเดียว ความล้มเหลวที่เริ่มต้นที่ขนาดเพย์โหลดคงที่คือหลักฐานที่หนักแน่น ขณะที่ความล้มเหลวที่ย้ายที่ไปมาไม่ใช่

ยืนยันการแก้ไขบนคำขอที่ล้มเหลว

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

dig +short www.example.com
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://www.example.com/
curl -sS -o /dev/null -w '%{http_code} %{size_download}\n' https://www.example.com/assets/app.js
ping -M do -s 1400 -c 3 203.0.113.20

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

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