ไอคอนสีเขียว ไอพีสาธารณะเดิม: VPN ข้ามเส้นทางใดไป

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

คลายเอนต์ติดตั้งอะไรจริง

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

ip route get 9.9.9.9
Find-NetRoute -RemoteIPAddress 9.9.9.9
route print -4

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

สามรูปแบบของการกำหนดเส้นทางแบบเลือก

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

grep -nE "redirect-gateway|route-nopull|route " /etc/openvpn/client/*.conf
ip route show table main | head -20

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

ฝั่งปลายทางต้องเขียนที่อยู่ต้นทางใหม่

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

sysctl net.ipv4.ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -S | grep MASQUERADE

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

การแปลงชื่อใช้เส้นทางของตัวเอง

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

resolvectl status | head -20
resolvectl query example.org

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

สี่ข้อสังเกตที่ทำให้ชัดเจน

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

curl -sS https://ifconfig.me/ip
ip route get 9.9.9.9

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