อินเทอร์เน็ตใช้ได้เฉพาะตอนเปิดแอป VPN เท่านั้นหรือ? ตรวจสอบสี่ชั้น
บน Windows แอป VPN จะทิ้งพร็อกซี่ อะแดปเตอร์เสมือน เส้นทาง และ DNS ไว้ ไล่ลงทีละสี่ชั้น พร้อมคำสั่ง Linux และ macOS สำหรับแต่ละชั้น
คุณลองใช้ไคลเอนต์ VPN ฟรีหรือส่วนขยายเบราว์เซอร์สักหนึ่งสัปดาห์ แล้วปิดมัน อินเทอร์เน็ตก็หยุดทำงาน ไอคอน Wi-Fi ยังแสดงว่ามีการเชื่อมต่อ อุปกรณ์อื่นบนเราเตอร์เดียวกันก็ปกติดี และสิ่งเดียวที่ทำให้ท่องเว็บได้อีกครั้งคือการเปิดแอปอีกครั้งหรือถอนการติดตั้งมัน รูปแบบนั้นไม่ใช่การเข้ารหัสที่สร้างการพึ่งพา แต่เป็นการกำหนดค่าที่แอปเขียนไว้ในที่ที่อุโมงค์ไม่ได้เป็นเจ้าของ
ไคลเอนต์แก้การตั้งค่าที่อุโมงค์ไม่ได้เป็นเจ้าของ
ไคลเอนต์เพื่อความเป็นส่วนตัวบน Windows หรือ macOS มักแตะสามที่พร้อมกัน มันตั้งพร็อกซี่ HTTP ของระบบ ซึ่งเป็นช่องเดียวกับที่ Internet Options แสดง มันติดตั้งอะแดปเตอร์เสมือน มักเป็นไดรเวอร์ TAP เพื่อดักจับแพ็กเก็ต และมันเขียนรายการตัวแปลงใหม่ ขณะที่เมื่อคุณกดตัดการเชื่อมต่อ สิ่งที่หายไปมีเพียงอุโมงค์
ส่วนขยายเบราว์เซอร์เป็นสิ่งที่แคบกว่า ปกติมันเปลี่ยนโปรไฟล์ของตัวเองหรือพร็อกซี่ที่เบราว์เซอร์ตัวหนึ่งใช้ นั่นคือเหตุผลที่เบราว์เซอร์ตัวเดียวล้มเหลวได้ขณะที่เครื่องมือบรรทัดคำสั่งยังทำงาน หรือกลับกัน คือส่วนขยายไม่เคยมีอำนาจแตะชั้นอื่นเลย ชั้นที่มันแก้ไขเป็นตัวกำหนดว่าเครื่องมือใดจะพัง
ไม่ว่าทางใด การตัดสินใจที่ค้างอยู่ถูกสร้างโดยซอฟต์แวร์ที่ไม่ต้องมีเหตุผลจะย้อนมัน อุโมงค์เป็นส่วนที่มองเห็น และเป็นส่วนเดียวที่มีเส้นทางปิดที่สะอาด ที่เหลือทั้งหมดคือการตั้งค่าในที่เก็บที่อายุยืนกว่ากระบวนการ ดังนั้นการถอนแอปจึงเป็นขั้นตอนเดียวที่ย้อนทั้งสามอย่างพร้อมกัน การอ่านที่เก็บเหล่านั้นก่อนติดตั้งใหม่คือสิ่งที่เปลี่ยนอาการให้เป็นการวินิจฉัย
สามสิ่งที่ค้างอยู่ สามความล้มเหลวที่ต่างกัน
สิ่งที่ค้างอย่างแรกคือพร็อกซี่ที่ชี้ไปที่ไม่มีอะไร: ช่องพร็อกซี่ LAN ยังถูกทำเครื่องหมายไว้ หรือที่อยู่สคริปต์กำหนดค่าที่ชี้ไปยังพอร์ต localhost ที่ไม่มีกระบวนการใดฟังอยู่แล้ว เบราว์เซอร์ส่งทุกคำขอไปยังพอร์ตที่ตายแล้วนั้นและค้างจนกว่าการหมดเวลาจะดูเหมือนเครือข่ายที่ตาย อย่างที่สองคืออะแดปเตอร์ที่ยังถือเส้นทางเริ่มต้น เพราะอุปกรณ์ TAP-Windows หรือไดรเวอร์เส้นทางของผู้ขายยังคงเป็นอินเทอร์เฟซจริงหลังถอนการติดตั้ง มันเก็บเส้นทางที่ได้รับไว้ และทราฟฟิกก็หายเข้าไปในอุโมงค์ที่ไม่มีอยู่ ไม่มีสิ่งที่ค้างใดประกาศตัวเอง ทั้งคู่ดูเหมือนระบบล่มทุกประการ
อย่างที่สามคือ DNS และมันล้มเหลวก่อนสองอย่างแรก หากรายการตัวแปลงมีแต่เซิร์ฟเวอร์ที่เข้าถึงได้ผ่านอุโมงค์ การค้นหาแต่ละครั้งจะหมดเวลาก่อนจะมีการร้องขอหน้าใดหน้าหนึ่ง เบราว์เซอร์จึงรายงานว่าเข้าถึงไซต์ไม่ได้แทนที่จะบอกว่าพร็อกซี่ตาย ไม่ว่าคุณจะมีแบบไหน ไม่มีสักอย่างที่เป็นระบบล่มในความหมายของเครือข่าย แต่ละอย่างเป็นสิ่งที่ค้างที่ไม่มีใครเพิกถอน และแต่ละอย่างถูกซ่อมในที่ที่ต่างกัน
ไล่ลงทีละสี่ชั้น
เริ่มจากที่ใกล้แอปพลิเคชันที่สุดแล้วไล่ลง เพราะชั้นต่างๆ ล้มเหลวตามลำดับการมองเห็นนั้น เปลี่ยนหนึ่งชั้นต่อการทดสอบหนึ่งครั้ง และทดสอบใหม่หลังแต่ละครั้ง การรีเซ็ตทุกอย่างพร้อมกันมักทำให้ท่องเว็บได้อีกครั้ง และทำให้คุณบอกไม่ได้ว่าสิ่งที่ค้างอย่างไหนเป็นเหตุ ดังนั้นการติดตั้งครั้งต่อไปจะสร้างปริศนาเดิมขึ้นมาอีก ลำดับคือพร็อกซี่ อะแดปเตอร์ เส้นทาง ตัวแปลง
บน Windows การตรวจแต่ละครั้งเป็นคำสั่งเดียวที่มาพร้อมระบบปฏิบัติการ จึงไม่ต้องติดตั้งอะไร รันตามลำดับและเก็บผลลัพธ์ไว้ด้วยกัน เพราะคำตอบทั้งสี่มีความหมายก็ต่อเมื่ออยู่ข้างกัน พวกมันรายงานพร็อกซี่ อะแดปเตอร์ เส้นทาง IPv4 และรายการตัวแปลง ตามลำดับนั้น:
netsh winhttp show proxy
Get-NetAdapter
route print -4
Get-DnsClientServerAddress
Linux และ macOS ต้องใช้คำสั่งของตัวเอง และใช้แทนกันไม่ได้ บน Linux เส้นทางมาจาก ip route และตัวแปลงมาจาก resolvectl status ในที่ที่ systemd-resolved เป็นเจ้าของ โดยถอยไปใช้ cat /etc/resolv.conf บน macOS เส้นทางมาจาก netstat -rn ตัวแปลงมาจาก scutil --dns และพร็อกซี่ของระบบมาจาก scutil --proxy ผู้อ่านบน macOS ที่รัน ip route จะได้ command not found และ /etc/resolv.conf ที่นั่นเป็นสตับที่สร้างขึ้น ไม่ใช่การกำหนดค่าที่เป็นทางการ ตรวจแพลตฟอร์มก่อนตรวจชั้น ไม่อย่างนั้นคำสั่งแรกจะกลายเป็นสิ่งที่ค้นพบเสียเอง
สำหรับแต่ละชั้น ถามคำถามเดียว: ค่านี้ยังชี้ไปที่สิ่งที่มีอยู่จริงขณะแอปปิดอยู่หรือไม่ พร็อกซี่ที่พอร์ตตายแล้ว อะแดปเตอร์ที่ไม่มีอุโมงค์ เส้นทางเริ่มต้นผ่านอินเทอร์เฟซที่ล่มไปแล้ว และตัวแปลงภายในอุโมงค์ ล้วนตอบว่าไม่ คำตอบว่าไม่เพียงข้อเดียวก็พอจะอธิบายอาการได้ นั่นคือเหตุผลที่การเปลี่ยนหนึ่งอย่างต่อการทดสอบหนึ่งครั้งสำคัญ
พร็อกซี่ไม่ใช่อุโมงค์
พร็อกซี่รับคำขอ ไปดึงมาจากที่อื่น แล้วส่งคำตอบกลับมา ซึ่งหมายความว่ามันรู้จุดหมายและเห็นทุกอย่างที่ไซต์ไม่ได้เข้ารหัสเอง มันไม่พกพาโปรโตคอลอื่น มันไม่ปกป้องเส้นทางเว้นแต่ปลายทางใช้ TLS อยู่แล้ว และมันถูกเปลี่ยนได้โดยอะไรก็ตามที่ติดตั้งมัน โดยไม่ต้องมีส่วนร่วมจากคุณ
ความแตกต่างนั้นเปลี่ยนคำถามที่ควรถาม เมื่อพร็อกซี่ถูกทิ้งไว้ ให้หาว่าโปรแกรมใดยังบังคับเบราว์เซอร์ของคุณอยู่ แทนที่จะถามว่าอุโมงค์ยังขึ้นอยู่หรือไม่ อุโมงค์อาจสมบูรณ์ดีและไม่เกี่ยวข้องกับความล้มเหลวเลย
หากคุณอยากรู้ว่าไคลเอนต์แบบนั้นทำอะไรจริงๆ ให้สังเกตมันแทนการอ่านแดชบอร์ด Process Monitor บันทึกว่ามันแตะรีจิสทรีคีย์และไฟล์ใด ขณะที่การดักจับแพ็กเก็ตเผยว่าทราฟฟิกของมันไปที่ไหน ทั้งคู่เป็นเครื่องมือธรรมดา และทั้งคู่ตอบคำถามเรื่องสิ่งที่ค้างได้ดีกว่าไฟสถานะใดๆ ไม่ต้องให้แอปยังทำงานอยู่เลย
ถอดส่วนประกอบ ไม่ใช่ถอดหลักฐาน
วิธีแก้ที่ยั่งยืนคือถอดสิ่งที่เขียนการตั้งค่านั้นออก ถอนการติดตั้งแอป ลบอะแดปเตอร์เสมือนที่มันเพิ่ม ล้างพร็อกซี่และรายการตัวแปลง จากนั้นรีบูตและทดสอบในขณะที่แอปยังถูกถอนอยู่ ถ้าท่องเว็บได้ตอนนั้น คุณพบสาเหตุแล้ว ไม่ใช่เพียงวิธีเลี่ยงชั่วคราว จดไว้ว่าชั้นใดค้างอยู่ เพราะผู้ขายรายเดิมมักส่งความผิดเดิมมาสองครั้ง
หากอาการกลับมาหลังติดตั้งไคลเอนต์ตัวถัดไป ให้ไล่สี่ชั้นอีกครั้งก่อนตัดสินว่าบริการทำอะไรเสีย หลักฐานมักยังอยู่ที่นั่น ในหนึ่งในสี่ที่นั้น แอปตัวที่สองไม่ได้สร้างชั้นที่ห้า มันแก้ไขหนึ่งในสี่
การติดตั้งใหม่รีเซ็ตพร็อกซี่แต่ไม่อาจรีเซ็ตอะแดปเตอร์ที่ค้าง และอาจทิ้งตัวแปลงไว้สองตัวในรายการ ความไม่สมมาตรนั้นคือเหตุผลที่ถอนแล้วทดสอบชนะปุ่มรีเซ็ตทุกอย่าง และยังให้ค่าฐานสำหรับเปรียบเทียบในครั้งถัดไปที่การเชื่อมต่อล่ม