OpenVPN ต่อไม่ติดบน Wi-Fi โรงแรม? ลอง TCP 443

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

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

เริ่มที่ไคลเอนต์: อ่านบรรทัดสถานะ

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

จากนั้นตรวจเครือข่ายด้วยเครื่องมือที่คุณมีอยู่แล้ว nc -vzu 203.0.113.10 1194 ส่งดาต้าแกรม UDP, curl -v telnet://203.0.113.10:443 รายงานว่าการจับมือ TCP เสร็จสมบูรณ์หรือไม่ และเบราว์เซอร์ที่โหลดหน้า HTTPS พิสูจน์เพียงว่าขาออก 443 ไปถึงโฮสต์เดียวนั้น การตรวจเล็ก ๆ ตอบสิ่งที่ไคลเอนต์ VPN ตอบไม่ได้: พอร์ตใดและโปรโตคอลใดออกจากเครือข่ายนี้ได้จริง

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

ย้ายตัวรับฟังและโปรไฟล์ไปพร้อมกัน

ฝั่งเซิร์ฟเวอร์ ตั้งตัวรับฟังตามที่เครือข่ายอนุญาต: port 443 และ proto tcp ในการตั้งค่าเซิร์ฟเวอร์ จากนั้นรีสตาร์ตบริการและยืนยันซ็อกเก็ตด้วย ss -lntp ฝั่งไคลเอนต์ โปรไฟล์ต้องสอดคล้อง เพราะการขนส่งและพอร์ตอยู่นอกอุโมงค์: proto tcp และ port 443 ใน .ovpn หรือฟิลด์ที่ตรงกันในหน้าจอตั้งค่าของแอป โปรไฟล์ที่ยังเล็ง UDP 1194 จะล้มเหลวเหมือนเดิมทุกประการ และความอยากโทษไฟร์วอลล์ที่แก้แล้วก็เกิดขึ้น ถ้าโฮสต์เดียวกันตอบ HTTPS บน 443 ด้วย ตัวรับฟังสองตัวแชร์ที่อยู่และโปรโตคอลนั้นไม่ได้ ให้ที่อยู่ที่สองแก่ VPN หรือวางตัวแยกสัญญาณไว้ข้างหน้า

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

เมื่อมีเพียงพร็อกซีที่ออกจากเครือข่าย

เครือข่ายแขกบางแห่งไม่อนุญาตอะไรนอกจากพร็อกซี HTTP ซึ่งเป็นข้อจำกัดที่ต่างจากพอร์ตปิดและตัดออกมากกว่า OpenVPN ไคลเอนต์ที่พูดได้แค่ PPTP, L2TP/IPsec หรือ IPsec เปล่าไม่มีทางผ่าน เพราะการออกแบบเหล่านั้นคาดว่าโปรโตคอลชั้นนอกจะไปถึงเซิร์ฟเวอร์โดยตรง OpenVPN ทำได้ ด้วย http-proxy proxy.example.net 8080 ในโปรไฟล์ไคลเอนต์ หากพร็อกซีอนุญาตวิธี CONNECT ไปยังพอร์ตของคุณ พร็อกซี SOCKS ยังง่ายกว่า เพราะส่งต่อสตรีมโดยไม่สนใจว่าข้างในมีอะไร

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

ตีราคาทางสำรองก่อนเก็บไว้ใช้

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

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