VPN ถูกบล็อกบนเครือข่ายที่เปิดเฉพาะเว็บ? ไล่ทีละชั้น

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

พิสูจน์ว่าชั้นไหนปฏิเสธการเชื่อมต่อ

อย่าเริ่มจากไคลเอนต์ VPN เริ่มจากคำขอ HTTPS ธรรมดาไปยังโฮสต์เดียวกันแล้วอ่านช่วงเวลา เพราะช่วงที่ล้มเหลวบอกว่าอุปกรณ์ใดรับผิดชอบ:

curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect} code=%{http_code}\n' \
  --max-time 8 https://vpn.example.net/

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

ตอนนี้ตรวจใบรับรองที่คุณได้รับจริง ๆ นี่คือวิธีเร็วที่สุดที่จะรู้ว่าคุณคุยกับเซิร์ฟเวอร์หรือกับกล่องกลางที่ลงนามเซสชันใหม่:

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

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

ไคลเอนต์ที่รู้จักพร็อกซีเปลี่ยนแพ็กเก็ตแรก ไม่ใช่นโยบาย

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

https_proxy=http://proxy.example.edu:3128 curl -v -o /dev/null https://vpn.example.net/
sudo openvpn --config /etc/openvpn/corp.conf --proto tcp-client \
  --remote vpn.example.net 443 --verb 4

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

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

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

พอร์ต 443 เข้าถึงได้ ไม่ใช่ได้รับอนุญาต

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

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

UDP มักเป็นเหยื่อรายแรก และควรยืนยันแทนการเดา ถ้า WireGuard หรือ OpenVPN ค่าเริ่มต้นไม่เคยทำแฮนด์เชคสำเร็จขณะที่ TCP 443 ทำงาน เครือข่ายกำลังทิ้ง UDP และการสร้างคีย์ใหม่ไม่ช่วยเปลี่ยน:

sudo wg show
dig +short vpn.example.net
dig +short vpn.example.net @1.1.1.1

เวลาของแฮนด์เชคที่ว่างเปล่าข้างเพื่อนที่ทำงานได้เมื่อวานคือคำตอบเรื่อง UDP คำถาม DNS สองข้อตอบคำถามอีกข้อ ถ้าตัวแก้ชื่อในเครื่องกับตัวแก้ชื่อสาธารณะไม่ตรงกันเรื่องที่อยู่ปลายทาง คุณกำลังถูกชี้นำ และข้อโต้แย้งเรื่องการขนส่งนั้นผิด

ตรวจสอบว่าอะไรออกจากเครื่องจริง ๆ

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

sudo tcpdump -ni any -c 20 'tcp port 443 and host 203.0.113.10'
sudo ss -tunp | grep -E ':(443|1194|51820)\b'

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

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

การย้อนกลับ และบันทึกที่ควรเก็บไว้

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

unset https_proxy http_proxy
sudo systemctl stop openvpn-client@corp
sudo ip route show default

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

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