OpenVPN ผ่านพร็อกซี HTTP: อ่านการตอบกลับ CONNECT ก่อน

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

พร็อกซีขนส่งอะไร และไม่ขนส่งอะไร

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

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

ตัวขนส่งต้องเป็น TCP ทั้งสองฝั่ง

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

proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128

ฝั่งเซิร์ฟเวอร์ต้องมีตัวรับฟัง TCP จริงบนพอร์ตที่ระบุในบรรทัด remote การเปลี่ยน proto udp เป็น proto tcp-client ในโปรไฟล์จะสร้างไคลเอนต์ที่คาดหวังสตรีม แต่ไม่ได้สร้างสตรีมที่อีกฝั่ง หากเซิร์ฟเวอร์เดียวกันตอบผ่าน UDP บนพอร์ตนั้นด้วย นั่นคือตัวรับฟังอีกตัว ไม่ใช่โหมดที่สองของตัวเดิม

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

อ่านการตอบกลับของพร็อกซีก่อนผลลัพธ์ของ VPN

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

CONNECT vpn.example.net:1194 HTTP/1.1
Host: vpn.example.net:1194

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

ข้อมูลรับรองของพร็อกซีและของ VPN มักเป็นตัวตนที่แตกต่างกันซึ่งอยู่ในมือของทีมที่แตกต่างกัน 407 ไม่ใช่รหัสผ่านผิดของบัญชี VPN และใบรับรองที่ถูกปฏิเสธไม่ใช่ปัญหาเรื่องสิทธิ์ของพร็อกซี

สิ่งที่ CONNECT ไม่เปิดเผย

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

มีรูปแบบแยกต่างหากที่องค์กรสิ้นสุดและตรวจสอบ TLS อย่างตั้งใจ รูปแบบเหล่านั้นต้องมีการกำหนดค่าความเชื่อถือของตนเองและการตัดสินใจเชิงนโยบายของตนเอง และไม่ใช่สิ่งที่บรรทัด http-proxy ธรรมดาขอ

ต้นทุนของ TCP ซ้อน TCP

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

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