OpenVPN ผ่าน SOCKS5: จับคู่เวอร์ชัน การขนส่ง และ DNS

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

จับคู่เวอร์ชัน SOCKS ก่อนไฟร์วอลล์

OpenVPN ชุมชนพูด SOCKS5 สำหรับ socks-proxy ชี้มันไปที่พร็อกซ์ที่ให้แค่ SOCKS4 การเชื่อมต่อ TCP จะเปิดแล้วค้าง เพราะไคลเอนต์รอคำตอบของคำทักทายที่อีกฝั่งไม่เคยแยกวิเคราะห์ จากภายนอก การค้างนั้นดูเหมือนพอร์ตที่ถูกกรองทุกประการ ซึ่งเป็นเหตุให้คำถามเรื่องเวอร์ชันมาก่อนกฎไฟร์วอลล์ใด ๆ การดึงข้อมูลที่รู้จัก SOCKS ตัดสินเรื่องนี้ได้ในคำสั่งเดียว

curl --socks5-hostname 127.0.0.1:9050 gw.lab.example

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

การดึงข้อมูลนั้นยังตัดกรณีล้มเหลวที่ล็อกไคลเอนต์ซ่อนไว้ออกด้วย พร็อกซ์อาจอนุญาตเบราว์เซอร์แต่ยังปฏิเสธปลายทาง VPN ซึ่งการปฏิเสธจะเกิดที่ CONNECT ก่อนการยืนยันตัวตน VPN ใด ๆ OpenVPN รายงานแค่การหมดเวลา คำตอบของพร็อกซ์เองจึงเป็นหลักฐานที่คุณต้องการ

การขนส่งต้องเป็น TCP ทั้งสองฝั่ง

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

proto tcp-client
remote gw.lab.example 8443
socks-proxy 127.0.0.1 9050

คำสั่งนี้รับโฮสต์พร็อกซ์ พอร์ตเสริม และไฟล์ข้อมูลรับรองเสริม ใส่ค่าเหล่านี้ในโปรไฟล์เองเพื่อให้สำเนาทำงานเหมือนกันที่อื่น

จำกัดทั้งห่วงโซ่ไว้ในคอนเทนเนอร์เดียว

การทำห่วงโซ่บนโฮสต์หมายถึงการยึดเส้นทางเริ่มต้นของมันและปล่อยตัวแปลงชื่อไว้ในสภาพที่ภายหลังไม่มีใครอธิบายได้ เนมสเปซหรือคอนเทนเนอร์จำกัดมันแทน โฮสต์จึงเก็บเส้นทางของตัวเองไว้ขณะที่จุดแวะ SOCKS และอุโมงค์อยู่ด้วยกัน ไม่มีอะไรเกิดขึ้นข้างในได้โดยไม่มีอุปกรณ์อุโมงค์ สิทธิ์ในการกำหนดค่าอุปกรณ์นั้น และพร็อกซ์ที่เข้าถึงได้ บริการ Compose ได้สิ่งนี้ด้วย cap_add: NET_ADMIN และ /dev/net/tun ที่เมานต์แบบ bind

cap_add:
  - NET_ADMIN
devices:
  - /dev/net/tun:/dev/net/tun

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

การแปลงชื่อคือจุดที่การแยกตัวล้มเหลว

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

docker compose exec vpn cat /etc/resolv.conf
docker compose exec vpn getent hosts internal.lab.example

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

พิสูจน์แต่ละจุดแวะตามลำดับ

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

curl --socks5-hostname 127.0.0.1:9050 gw.lab.example
docker compose exec vpn ip route get 203.0.113.10
docker compose exec vpn getent hosts internal.lab.example

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

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