VPN เชื่อมต่อแล้วแต่ไม่มีอินเทอร์เน็ต? ตรวจสอบสี่ชั้น

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

เริ่มจากเครือข่ายที่คุณมาจาก

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

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

ตัดสินว่าความล้มเหลวคือการแปลงชื่อหรือไม่

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

nslookup example.com

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

อุโมงค์เต็มหรือเฉพาะซับเน็ตของบริษัท

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

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

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

เมื่อเซิร์ฟเวอร์ไม่ส่งต่ออะไรเลย

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

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

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

ตรวจทีละชั้น

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

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://example.com
route print -4          # Windows
ip -4 route show        # Linux
netstat -rn | head      # macOS

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