ทำไมพอร์ทัลจับ captive จึงบล็อก VPN ของคุณ และวิธีลงชื่อเข้าใช้อีกครั้ง
Wi-Fi สาธารณะอนุญาตอุปกรณ์ของคุณก่อนที่แพ็กเก็ตแรกจะออกไป พอร์ทัลทิ้งอะไร ทำไม VPN ของคุณรายงานผิด และลำดับที่เชื่อมคุณกลับมา
ในเครือข่ายเปิด จุดเข้าถึงของคุณไม่ได้ส่งแพ็กเก็ตให้อินเทอร์เน็ตเฉยๆ จุดนโยบายด้านบนตรวจสอบว่าอุปกรณ์ของคุณได้รับอนุญาตแล้วหรือยัง และจนกว่าจะได้รับอนุญาต เกือบทุกอย่างจะถูกทิ้ง ไคลเอนต์ VPN ของคุณอ่านความเงียบนั้นว่าเป็นเซิร์ฟเวอร์ที่ตายแล้ว มันแทบไม่บอกเช่นนั้น WireGuard ส่งแฮนด์เชกซ้ำไปในความว่างเปล่า OpenVPN รายงานการหมดเวลาของการเชื่อมต่อ และ IKEv2 กลับมาเป็นข้อผิดพลาด 809 เกี่ยวกับเซิร์ฟเวอร์ระยะไกลที่ไม่ตอบสนอง
พอร์ทัลควบคุมอะไรจริงๆ
พอร์ทัลจับ captive คือสองสิ่งติดกัน จุดตัดสินใจเชิงนโยบายและตัวเปลี่ยนเส้นทาง เมื่ออุปกรณ์ของคุณเชื่อมต่อและรับสัญญาณ DHCP เครือข่ายจะวางคุณไว้ในสถานะก่อนการอนุญาต
สถานะนั้นคือชุดกฎไฟร์วอลล์ โดยปกติอนุญาต DNS และอนุญาต HTTP หรือ HTTPS ไปยังรายการโฮสต์พอร์ทัลสั้นๆ และทิ้งทุกอย่างอื่น รายการที่อนุญาตคือสวนที่มีกำแพงล้อม และแทบไม่เคยมีปลายทาง VPN รวมอยู่ด้วย
ไม่มีการทิ้งใดสุภาพ แพ็กเก็ตที่ส่งไปยังเซิร์ฟเวอร์ VPN ถูกทิ้งแทนที่จะถูกปฏิเสธ ไคลเอนต์จึงไม่ได้รับทั้ง ICMP unreachable และ TCP reset ได้เพียงการไม่มีคำตอบ ขึ้นอยู่กับผู้ผลิต ตัวเปลี่ยนเส้นทางอาจตอบพอร์ต 80 ด้วยการเปลี่ยนเส้นทางไปยังหน้าลงชื่อเข้าใช้ ขณะที่พอร์ต 443 ถูกทิ้งหรือถูกดัก การเปลี่ยนเส้นทางสังเกตได้ง่ายเพราะพาคำตอบ HTTP ธรรมดา การดักที่ 443 ต้องใช้ใบรับรองที่เบราว์เซอร์ของคุณจะปฏิเสธที่จะเชื่อถือ
การอนุญาตเองมักผูกกับที่อยู่ MAC ของอุปกรณ์ บางครั้งผูกกับ IP ที่เช่า และมันอยู่ในตารางเซสชันที่มีตัวจับเวลา การลงชื่อเข้าใช้สร้างรายการ กฎไฟร์วอลล์ที่ให้ทราฟฟิกของคุณผ่านมีอยู่เพียงตราบเท่าที่รายการนั้นมีอยู่ และนั่นคือเหตุผลที่ปัญหาทั้งหมดกลับมาภายหลังโดยไม่มีอะไรเปลี่ยนฝั่งคุณ
ทำไมแฮนด์เชกของ VPN ตายก่อนจะเริ่ม
แต่ละโปรโตคอลมีทรานสปอร์ตของตัวเอง และไฟร์วอลล์ก่อนการอนุญาตทำลายแต่ละตัวต่างกัน IKEv2 บน Windows และ iOS วิ่งบน UDP 500 และ UDP 4500 การทิ้งบนพอร์ตเหล่านั้นปรากฏเป็น 809 หรือเป็นความล้มเหลวแบบการแก้ชื่อบนไคลเอนต์ที่รายงานแต่ละระยะแยกกัน OpenVPN บน UDP 1194 อยู่ในสถานะกำลังเชื่อมต่อจนกว่าจะหมดเวลา OpenVPN บน TCP 443 เป็นกรณีที่น่าสนใจ เพราะพอร์ทัลอาจทำแฮนด์เชก TCP ให้เสร็จแล้วตอบด้วยหน้าของตัวเอง คุณจึงเห็นข้อผิดพลาด TLS แทนการหมดเวลา
WireGuard แสดงกลไกนี้ชัดที่สุด มันเป็น UDP เท่านั้นตามการออกแบบ ไม่มีทางเลือก TCP ไฟร์วอลล์ที่ทิ้ง UDP ที่ไม่รู้จักจึงตัดทรานสปอร์ตออกทั้งหมด ไคลเอนต์ยังคงส่งการเริ่มแฮนด์เชกด้วยช่วงพักที่เพิ่มขึ้นและรายงานแฮนด์เชกที่ไม่เคยเสร็จ ไม่มีอะไรในข้อความนั้นกล่าวถึง Wi-Fi และไม่มีอะไรบ่งบอกว่าคุณควรเปิดเบราว์เซอร์
แพลตฟอร์มพยายามสังเกตสถานะก่อน VPN ของคุณ Windows ดึง URL ที่รู้จักเพื่อตัดสินว่าจะแสดงการแจ้งเตือนลงชื่อเข้าใช้หรือไม่ Android ขอปลายทางที่ควรตอบ 204 No Content และอุปกรณ์ Apple เปิดหน้าต่างเครือข่ายจับขนาดเล็ก การตรวจเหล่านั้นได้ผลเพราะพอร์ทัลตอบด้วยการเปลี่ยนเส้นทางแทนเนื้อหาที่คาดไว้ พฤติกรรมเดียวกันอธิบายว่าทำไมพอร์ทัลดูสมบูรณ์ดีได้ขณะที่อุโมงค์ของคุณตาย การตรวจและอุโมงค์ถูกตัดสินด้วยกฎต่างกัน
การหมดอายุเซสชันรีเซ็ตอะไรจริงๆ
สถานที่ทำให้เซสชันหมดอายุด้วยเหตุที่ไม่เกี่ยวกับบัญชี VPN ของคุณ การหมดเวลาไม่มีการใช้งาน ความยาวเซสชันสูงสุด สัญญาณ DHCP ใหม่ หรือการเชื่อมต่อใหม่กับจุดเข้าถึงอื่น เมื่อตัวจับเวลาทำงาน รายการในตารางเซสชันหายไปและชุดกฎก่อนการอนุญาตกลับมาเหมือนตอนลงทะเบียนทุกประการ
อุโมงค์ที่สร้างแล้วมักมีชีวิตนานพอที่จะดูสมบูรณ์ ข้อความคงการเชื่อมต่อยังคงออกไป และไคลเอนต์จะสังเกตหรือไม่ขึ้นอยู่กับวิธีจัดการทราฟฟิกที่ไม่มีการตอบ ไฟสถานะจึงอาจเขียวอยู่ระยะหนึ่งหลังจากเส้นทางหายไป จากนั้นอุโมงค์ก็ล้มและการเชื่อมต่อใหม่ทุกครั้งล้มเหลวบนพอร์ตที่ถูกบล็อกเดิม
เมื่อถึงตอนนั้น ข้อผิดพลาดของไคลเอนต์บอกคุณว่าอยู่ระยะใด หากอ่านอย่างตั้งใจ
| Symptom | What it means | Next check |
|---|---|---|
| Handshake times out with no reply | Pre-authorization drop on UDP | Load any HTTP page and see whether the portal appears |
| Immediate TLS error on 443 | The portal answered your TCP connection | Authorize, then retry the same profile |
| Authentication rejected | Your credentials reached the server | The network is fine, so treat this as an account problem |
| Connects, then drops repeatedly | Session or lease churn | Watch the portal timer and the lease time |
รายละเอียดหนึ่งทำให้คนเข้าใจผิด เมื่อเซสชันผูกกับที่อยู่ MAC การโหลดหน้าลงชื่อเข้าใช้ซ้ำอาจไม่ช่วย คุณต้องปล่อยการเชื่อมต่อและเข้าร่วมใหม่ เพื่อให้พอร์ทัลเห็นความพยายามอนุญาตใหม่แทนที่อันที่หมดอายุ
ลงชื่อเข้าใช้ก่อน แล้วจึงยกอุโมงค์
ลำดับที่ได้ผลคือ อนุญาตอุปกรณ์ พิสูจน์เส้นทาง เริ่ม VPN พิสูจน์อุโมงค์ แล้วคืนการบล็อกตามปกติของคุณ ขั้นสุดท้ายนั้นสำคัญเพราะสถานะชั่วคราวที่คุณต้องใช้เพื่อไปถึงพอร์ทัลคือสถานะที่สวิตช์ฉุกเฉินมีไว้เพื่อป้องกัน
ไคลเอนต์เดสก์ท็อปที่มีตัวเลือกบล็อกนอกอุโมงค์ต้องหยุดชั่วคราวเพื่อให้หน้าพอร์ทัลโหลด และควรปิดแอปที่ละเอียดอ่อนไว้ในช่วงนอกอุโมงค์นั้น มันเป็นช่วงเดียวที่ทราฟฟิกในเครื่องออกไปโดยไม่มีการป้องกัน อุปกรณ์ที่จัดการและเปิดตลอดควรใช้ขั้นตอนที่เจ้าของเผยแพร่แทนที่คุณจะถอดนโยบาย หากพอร์ทัลแสดงคำเตือนใบรับรอง ให้หยุด การยอมรับจะพาเซสชันของคุณผ่านพร็อกซีดักของสถานที่ และพร็อกซีนั้นอ่านทุกอย่างที่คุณส่งได้ บน Android การล็อกภายใต้ VPN ที่เปิดตลอดจะบล็อกทราฟฟิกก่อนอุโมงค์ขึ้น และบางบิลด์ไม่สามารถยกเว้นโฟลว์ของพอร์ทัลได้ หากของคุณทำไม่ได้ ให้ใช้การเข้าถึงทางเลือกของสถานที่หรืออุปกรณ์อื่นแทนการปล่อยการล็อกไว้ปิด กฎ on-demand ของ Apple เขียนให้ปฏิเสธอุโมงค์จนกว่าการตรวจจะสำเร็จได้ และนั่นคือพฤติกรรมที่คุณต้องการในเครือข่ายโรงแรม
ตรวจสอบตามลำดับด้วยเครื่องมือที่มีอยู่ ก่อนอุโมงค์ ให้รันการตรวจโดยเห็นทั้งหัวเรื่องและเนื้อหา และดูว่าทรานสปอร์ต VPN ได้รับคำตอบใดๆ หรือไม่
curl -sS -D - http://captive.apple.com/hotspot-detect.html -o -
sudo tcpdump -ni any 'udp port 500 or udp port 4500 or udp port 1194'ก่อนการอนุญาต พอร์ทัลปกติให้หนึ่งในสองคำตอบ คือ 302 ที่ Location ชี้ไปยังหน้าลงชื่อเข้าใช้ หรือ 200 ที่มีเนื้อหา HTML ซึ่งเป็นหน้าพอร์ทัล จดว่าได้อันไหน การเปลี่ยนเส้นทางก่อนลงชื่อเข้าใช้ไม่ใช่ความล้มเหลว พอร์ทัลกำลังบอกคุณว่าต้องไปที่ใด หลังจากพอร์ทัลรายงานความสำเร็จ ให้ทำคำสั่งซ้ำและคาดหวัง 200 ที่เนื้อหาเป็นคำว่า Success ตามตัวอักษร สตริงนั้นทำให้การตรวจมีความหมาย หากโฮสต์ตอบตามปกติก่อนที่คุณจะเคยลงชื่อเข้าใช้ แสดงว่าไม่มีพอร์ทัลดักในเครือข่ายนี้ ในการดัก การทิ้งก่อนการอนุญาตคือแพ็กเก็ตขาออกที่ไม่มีอะไรกลับมา ขณะที่เส้นทางที่ใช้งานได้แสดงคำตอบต่อโฟลว์เดียวกันภายในประมาณหนึ่งวินาที เชื่อมต่อ แล้วทำการดักซ้ำ
หากอุโมงค์ยังล้มเหลวหลังจากพอร์ทัลบอกว่าใช่
ความสำเร็จในการลงชื่อเข้าใช้ไม่เหมือนทรานสปอร์ตที่ได้รับอนุญาต หลายสถานที่อนุญาตพอร์ทัลและการท่องเว็บปกติแต่บล็อก UDP ทั้งหมด ซึ่งทำให้ WireGuard และ UDP OpenVPN เสียและ TCP 443 ทำงานได้ หาก TCP 443 ผ่านแต่ UDP ไม่ผ่าน นั่นคือนโยบายของสถานที่ ไม่ใช่ไคลเอนต์ที่คุณตั้งค่าผิด ดังนั้นเปลี่ยนทรานสปอร์ตหรือยอมรับข้อจำกัดและไปต่อ หากการเชื่อมต่อใหม่ยังล้มเหลวหลังจากนั้น ให้เก็บข้อผิดพลาดที่แน่นอนไว้ มันระบุระยะที่คุณติดอยู่
ความล้มเหลวอื่นอยู่บนอุปกรณ์ เซสชันที่ยังผูกกับ MAC เก่า อะแดปเตอร์ Wi-Fi ตัวที่สองที่มีสัญญาณของตัวเอง หรือไคลเอนต์ที่แคชข้อยกเว้นใบรับรองของพอร์ทัล แต่ละอย่างยังล้มเหลวต่อได้หลังการอนุญาตใหม่ที่สะอาด ปล่อยการเชื่อมต่อ อนุญาตใหม่ และลองหนึ่งครั้งก่อนแตะการตั้งค่าไคลเอนต์ RFC 8952 คุ้มค่าที่จะอ่านหากคุณต้องการสถาปัตยกรรมเบื้องหลังองค์ประกอบที่คุณสังเกต
หากพอร์ทัลเองปฏิเสธที่จะอนุญาต ปัญหาอยู่ที่บัญชีหรือการจัดสรรอุปกรณ์ และไม่มีการตั้งค่า VPN ใดแก้ได้ การเปลี่ยนประเทศทางออกของ VPN ไม่รีเซ็ตสถานะการเข้าถึงในท้องถิ่นของสถานที่ ตารางนั้นผูกกับอุปกรณ์ของคุณ ไม่ใช่เซิร์ฟเวอร์ที่คุณเลือก ถามผู้ดำเนินการของสถานที่และให้เวลา เพราะตารางเซสชันคือสิ่งที่เขาจะดู
ก่อนการเดินทางครั้งถัดไป จดสามอย่าง หน้าพอร์ทัลเป็นขั้นที่ศูนย์ ขั้นหยุดการบล็อกสำหรับอุปกรณ์ทุกเครื่องที่คุณพกไป และทรานสปอร์ตสำรองหนึ่งอย่างที่คุณทดสอบจริง เมื่ออุโมงค์ที่ทำงานเมื่อสิบนาทีก่อนหยุดอีกครั้ง ให้ถือว่าเป็นการอนุญาตที่หมดอายุและตรวจพอร์ทัลอีกครั้งก่อนแตะโปรไฟล์ VPN