ฟิลด์ Proxy ในโปรไฟล์ VPN ของ Apple ทำอะไรจริง ๆ
การกรอกฟิลด์พร็อกซีไม่ได้เปลี่ยน VPN ให้เป็น HTTP มีการเชื่อมต่อสองส่วนเกี่ยวข้อง และฟิลด์นี้ไปถึงเพียงส่วนเดียว
การกรอกฟิลด์ Proxy ในการตั้งค่า VPN ของ Apple ให้ความรู้สึกว่าควรเปลี่ยนเส้นทางอุโมงค์ผ่านพอร์ตเว็บ แต่ก็ไม่ได้ทำเช่นนั้น ฟิลด์นี้เลือกตัวกลางระดับแอปพลิเคชันสำหรับทราฟฟิกที่แอปที่เข้ากันได้เลือกจะส่งไปที่นั่น ส่วนการเชื่อมต่อของไคลเอนต์ VPN เองกับเกตเวย์นั้นถูกกำหนดโดยโปรโตคอล ตัวรับฟัง และการขนส่งที่คุณตั้งค่าไว้ และสิ่งเหล่านี้เป็นการตัดสินใจแยกกัน
สองการเชื่อมต่อ สองเจ้าของ
การตั้งค่าแบบนี้ทุกแบบมีการเชื่อมต่อจากไคลเอนต์ไปยังเกตเวย์ และการเชื่อมต่อจากแอปไปยังปลายทาง ส่วน Proxy พูดถึงอันที่สอง แม้จะอยู่ในโปรไฟล์เดียวกับอันแรก
| Connection | What decides its behaviour |
|---|---|
| VPN client to VPN gateway | The supported protocol, the listening port, the transport and the network policy in between |
| Application to a selected proxy | The application's own proxy support, the configured proxy policy, and the route to that next hop |
เอกสารอ้างอิงการตั้งค่าพร็อกซีของ Apple ระบุ HTTP, HTTPS, SOCKS และการกำหนดค่าพร็อกซีอัตโนมัติ ซึ่งอธิบายตัวเลือกพร็อกซีของแอป ไม่มีรายการใดบอกว่าแพ็กเก็ต IPsec หรือ WireGuard ไปถึงเกตเวย์ได้อย่างไร
นี่คือการตรวจสอบเร็ว ๆ ที่ชี้ขาด คุณบอกพอร์ตและโปรโตคอลที่ไคลเอนต์ VPN รายงานในบันทึกได้เลย ถ้าบรรทัดนั้นยังบอกว่า UDP 500 หรือ UDP 51820 ฟิลด์พร็อกซีก็ไม่ได้เปลี่ยนอะไรในบรรทัดนั้น
เมื่อใดฟิลด์นี้คือเครื่องมือที่ถูกต้อง
มีกรณีจริงที่พร็อกซีอยู่หน้าอุโมงค์ แต่ นั่นเป็นคุณสมบัติของไคลเอนต์ ไม่ใช่ฟิลด์ในโปรไฟล์ คู่มือ OpenVPN ระบุ --http-proxy สำหรับการเชื่อมต่อ TCP ที่ขนส่งผ่านพร็อกซี HTTP CONNECT การใช้ต้องมีตัวเลือกไคลเอนต์ที่ตรงกัน เกตเวย์ที่เข้าถึงได้ด้วยวิธีนั้น และพร็อกซีที่อนุญาต CONNECT ไปยังพอร์ตที่ใช้
ถ้าไคลเอนต์ของคุณมีตัวเลือกนั้นและเครือข่ายอนุญาต CONNECT ไปยังพอร์ต ก็อาจทำงานได้ ถ้าไคลเอนต์ไม่มี การกรอกพร็อกซีของระบบก็ไม่มีผลต่ออุโมงค์เลย
เมื่อใดจึงไม่เปลี่ยนอะไร
โปรไฟล์ IKEv2 หรือ IPsec ไม่กลายเป็นอุโมงค์ HTTP เพราะฟิลด์พร็อกซีถูกกรอก WireGuard ก็เช่นกัน ซึ่งรูปแบบการกำหนดค่าไม่รู้จักแนวคิดพร็อกซี การเปลี่ยนพอร์ตเกตเวย์ก็ไม่เปลี่ยนโปรโตคอลของมัน และปลายทางที่ตอบ HTTPS ปกติก็ไม่ใช่ตัวรับฟัง VPN โดยอัตโนมัติ
กับดักเดียวกันนี้จับคนที่คัดลอกโปรไฟล์ยุค PPTP จากคู่มือ iPad เก่า ตัวเลือกยังอยู่ในอินเทอร์เฟซ แต่บริการเบื้องหลังไม่ได้พูดโปรโตคอลนั้นแล้ว
ตัดสินใจว่าจะแก้ชั้นไหน
ถามว่าชั้นไหนล้มเหลวก่อนจะเปลี่ยนอะไร ถ้าไคลเอนต์สร้างเซสชันไม่ได้ ปัญหาอยู่ที่การขนส่งและฟิลด์พร็อกซีไม่เกี่ยวข้อง ถ้าอุโมงค์ทำงานแต่แอปหนึ่งไปไม่ถึงเซิร์ฟเวอร์ของตน ควรตรวจพร็อกซีของแอป ถ้าอุโมงค์ทำงานและทุกแอปล้มเหลว ผู้ต้องสงสัยคือการกำหนดเส้นทางและ DNS ภายในอุโมงค์
สำหรับกรณีแรก ให้ถามผู้ให้บริการว่าสนับสนุนการขนส่งหรือเครือข่ายทางเลือกที่อนุมัติแล้วแบบใด OpenVPN บน TCP 443 มีอยู่เพราะบางเครือข่ายอนุญาตเฉพาะสิ่งนั้น และยังต้องให้เซิร์ฟเวอร์รับฟังอยู่
อย่าถือว่าพอร์ต UDP ที่ถูกบล็อกเป็นการอนุญาตให้คิดหาทางเอง รักษาการตรวจสอบใบรับรองหรือตัวตนของเกตเวย์ไว้ อย่าปิดมันเพื่อให้แฮนด์เชกเข้ากัน
ยืนยันทั้งสองชั้นทีละชั้น
ยืนยันอุโมงค์ก่อน ดูที่หน้าสถานะของไคลเอนต์ว่ามีเซสชันที่สร้างขึ้นและจำนวนไบต์ที่ไม่เป็นศูนย์ จากนั้น อ่านการตั้งค่าพร็อกซีโดยตรง โดยใช้ scutil --proxy สำหรับการกำหนดค่าที่มีผล หรือ networksetup -getwebproxy Wi-Fi สำหรับค่าที่บันทึกไว้ จากนั้นทดสอบแอปหนึ่งที่เคารพพร็อกซีของระบบและอีกหนึ่งที่เพิกเฉย เพราะแอปเนทีฟจำนวนมากเพิกเฉย
สามผลลัพธ์ สามวิธีแก้ที่ต่างกัน
ถ้าทั้งสองชั้นรายงานความสำเร็จแต่แอปยังล้มเหลว ให้ดูการแยกอุโมงค์ DNS และการตั้งค่าเครือข่ายของแอปเอง นั่นคือชั้นที่สาม และก็ไม่ใช่ฟิลด์พร็อกซีเช่นกัน