VPN ค้างที่ Connecting ในโหมดเครื่องบิน: หาลิงก์ขาขึ้นให้เจอ
ไคลเอนต์ที่ค้างอยู่ที่ Connecting ในโหมดเครื่องบินอาจไม่มีลิงก์ขาขึ้นเลย แยกสถานะวิทยุ การเชื่อมต่อ การลงชื่อเข้าพอร์ทัล และนโยบายบล็อกออกจากกัน
โทรศัพท์แสดงไอคอนเครื่องบิน ไคลเอนต์ VPN ค้างอยู่ที่ Connecting สองนาทีแล้ว และโปรไฟล์ก็ถูกต้อง มันทำงานได้เมื่อชั่วโมงก่อนในอาคารเดียวกัน ไม่มีอะไรเสีย: VPN คือการเชื่อมต่อที่ถูกพาไปโดยอีกระบบเครือข่าย และโหมดเครื่องบินเพิ่งถอดเครือข่ายที่พามันไปออก ไคลเอนต์จึงพยายามซ้ำเพราะนั่นคือสิ่งที่มันทำเมื่อไม่มีลิงก์ขาขึ้น
สิ่งที่ทำให้สับสนคือไอคอนเครื่องบินไม่ได้บอกว่ามี Wi-Fi หรือไม่ และ Connecting ก็ไม่ได้บอกว่าไคลเอนต์กำลังพิสูจน์ตัวตนหรือแค่รอ แยกสองสิ่งนี้ออกจากการอ่านครั้งเดียว แล้วการวินิจฉัยจะใช้เวลาแค่นาทีเดียว
ไอคอนเครื่องบินไม่ใช่รายงานวิทยุ
บนอุปกรณ์ Android ที่รองรับ Wi-Fi และ Bluetooth สามารถเปิดอยู่ได้ในโหมดเครื่องบิน และอุปกรณ์จำตัวเลือกที่คุณทำครั้งล่าสุดไว้ คำแนะนำของ Google เกี่ยวกับโหมดเครื่องบินบน Pixel อธิบายพฤติกรรมนั้นไว้พอดี ดังนั้นไอคอนอาจหมายถึงแค่เซลลูลาร์ปิดอยู่ และไม่มีอะไรอื่น
ตรวจสอบสถานะจริงแทนที่จะดูสัญลักษณ์บนจอ adb shell settings get global airplane_mode_on คืนค่า 0 หรือ 1 สำหรับโหมดเอง และ adb shell dumpsys connectivity แสดงรายการเครือข่ายที่อุปกรณ์มีอยู่ตอนนี้พร้อมสถานะการตรวจสอบ สองเอาต์พุตนี้ด้วยกันตอบคำถามที่ไอคอนตอบไม่ได้
ถ้า Wi-Fi ปิดอยู่ หรือเปิดแต่ไม่ได้เชื่อมกับอะไรเลย ก็ไม่มีเส้นทางไปยังปลายทาง VPN และต่อให้เชื่อมใหม่กี่ครั้งก็สร้างเส้นทางไม่ได้ นี่คือกรณีที่ควรตัดออกก่อน เพราะเป็นกรณีเดียวที่วิธีแก้ที่ถูกต้องอยู่นอกแอป VPN
Connecting หมายความว่าอะไรจริง ๆ
ไคลเอนต์สามารถถือโปรไฟล์ที่บันทึกไว้ แสดงชื่อ และหมุนตัวบ่งชี้โดยไม่เคยติดต่ออะไรเลย การกำหนดค่าเป็นเรื่องในเครื่อง การสร้างอุโมงค์ต้องมีเซิร์ฟเวอร์ที่เข้าถึงได้ การจับมือที่เสร็จสมบูรณ์ และอินเทอร์เฟซสำหรับกำหนดเส้นทาง เฉพาะส่วนสุดท้ายเท่านั้นที่ต้องมีเครือข่ายที่ทำงานได้ นี่คือเหตุผลที่สองส่วนแรกดูสำเร็จได้แม้วิทยุปิด
ดังนั้นตัวบ่งชี้จึงสอดคล้องกับอย่างน้อยสามสถานการณ์ที่ต่างกัน: ไม่มีลิงก์ขาขึ้นเลย ลิงก์ขาขึ้นที่ไปไม่ถึงปลายทาง และลิงก์ขาขึ้นที่ไปถึงแต่พิสูจน์ตัวตนไม่ผ่าน บนหน้าจอทั้งสามดูเหมือนกัน และในบันทึกต่างกันโดยสิ้นเชิง ดังนั้นสิ่งที่ใช้ประโยชน์ได้ชิ้นแรกในทุกกรณีคือบันทึก ไม่ใช่การลองอีกครั้ง
เอกสาร VPN ของ Android เองก็ลากเส้นเดียวกันระหว่างการสร้างการเชื่อมต่อกับนโยบายเปิดตลอดและบล็อกที่แยกจากกัน การแยกนี้คือเหตุผลที่โทรศัพท์ดูเหมือนได้รับการปกป้องขณะออฟไลน์แต่กลับไม่มีอุโมงค์
สี่สถานะที่ควรแยกให้ออก
สี่สถานะด้านล่างนี้คือสิ่งที่ควรตั้งชื่อ เพราะหน้าจอแสดงทั้งสี่เหมือนกัน
| State | What you will see | What to do |
|---|---|---|
| Airplane mode, Wi-Fi off | No networks in dumpsys, VPN retries forever | Turn Wi-Fi on, or accept that the tunnel cannot exist |
| Wi-Fi on, not associated | Interface exists, no default network | Join the access point |
| Associated, not validated | Network listed, captive-portal flag set | Complete the portal sign-in, then reconnect |
| Validated, tunnel down | Internet works, VPN fails or blocks | Debug the tunnel, not the radio |
แถวที่สามจับคนส่วนใหญ่ในโรงแรมและสนามบิน การเชื่อมต่อไม่ใช่การอนุญาตให้ผ่าน: พอร์ทัลที่ยังไม่ปล่อยโทรศัพท์ผ่านจะรับรหัสผ่าน Wi-Fi อย่างยินดี แล้วปฏิเสธที่จะส่งทราฟฟิกไปยังปลายทาง VPN การลงชื่อเข้าผ่านเบราว์เซอร์ก่อนขณะอุโมงค์ปิดมักเป็นทางเดียว
ทำไมการบล็อกทำให้ดูแย่ลง
ถ้าเปิดทั้ง VPN ตลอดเวลาและการบล็อกการเชื่อมต่อที่ไม่มี VPN แอปที่ครอบคลุมทุกตัวจะถูกบล็อกทุกครั้งที่อุโมงค์ไม่ขึ้น นี่คือคุณสมบัติที่ทำงาน ไม่ใช่ความผิดพลาดที่สอง อาการเปลี่ยนจากแอปเดียวล้มเหลวเป็นทุกอย่างล้มเหลว ซึ่งอ่านดูเหมือนปัญหาใหญ่กว่ามาก
ยังอธิบายลำดับที่คนอ่านผิด: โหมดเครื่องบินเปิด ไม่มีลิงก์ขาขึ้น แอปถูกบล็อก VPN บอกว่า connecting การบล็อกคือการที่นโยบายทำหน้าที่ของมัน การปิดนโยบายเพื่อทดสอบลิงก์ขาขึ้นจะถอดการป้องกันที่คุณคงต้องการออก และไม่สอนอะไรเลย
ให้ตรวจขอบเขตแทน แอปใดถูกครอบคลุม แอปใดถูกยกเว้น และโปรไฟล์เป็นรายผู้ใช้หรือทั้งอุปกรณ์ งานที่เริ่มแอป VPN ทันทีที่ Wi-Fi ปรากฏคือทริกเกอร์ ไม่ใช่การรับประกันว่าจะไม่มีแพ็กเก็ตออกไปก่อนมันทำงาน
ลำดับการวินิจฉัยที่หยุดการเดา
ทำงานจากล่างขึ้นบน ยืนยันโหมด ยืนยันว่ามีเครือข่าย ว่าถูกตรวจสอบแล้ว ว่าสามารถเข้าถึงอะไรบางอย่างนอกซับเน็ตท้องถิ่น แล้วจึงดูไคลเอนต์ adb shell ping -c 3 1.1.1.1 เป็นการทดสอบแบบหยาบ แต่แยกเส้นทางที่ขาดหายออกจากเส้นทางที่มีอยู่ขณะอุโมงค์ไม่พอใจ
ถ้า ping ล้มเหลวขณะมีเครือข่ายอยู่ในรายการ ปัญหาอยู่เหนือ VPN ขึ้นไป และไม่มีตั้งค่าใดในไคลเอนต์ที่จะแก้ได้ ถ้า ping สำเร็จแต่อุโมงค์ยังไม่ถูกสร้าง ให้เก็บบันทึกของไคลเอนต์ ณ ขณะนั้น: ข้อผิดพลาดจะแยกการหมดเวลาออกจากการปฏิเสธการพิสูจน์ตัวตน และสองสิ่งนี้ไม่มีอะไรเหมือนกัน
จบด้วยการคืนสถานะที่ตั้งใจไว้: อนุญาต Wi-Fi ในโหมดเครื่องบินถ้านั่นคือการตั้งค่าปกติของคุณ พอร์ทัลเสร็จสมบูรณ์ และเปิดนโยบายบล็อกกลับมา จากนั้นเชื่อมต่อใหม่หนึ่งครั้งและยืนยันว่าอุโมงค์ขึ้นเอง เพราะการกำหนดค่าที่ทำงานได้เฉพาะหลังการลองด้วยมือจะล้มเหลวอีกครั้งในการบูตครั้งถัดไป