หนึ่งพอร์ต OpenVPN สามบริการ: ทำไมพอร์ตภายในจึงสำคัญ

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

กระแสภายนอกบรรทุกอะไร และซ่อนอะไร

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

ดังนั้นการดักจับบนอินเทอร์เฟซ WAN จึงแสดงบทสนทนาเดียว ไม่ใช่สาม พอร์ตภายในจะปรากฏหลังการถอดห่อเท่านั้น นี่คือเหตุผลที่ช่องเปิดไฟร์วอลล์ช่องเดียวสามารถบรรทุก SSH, HTTPS และ DNS ได้ในเวลาเดียวกัน

# WAN side: one outer tuple, whatever the inner services are
tcpdump -ni wan0 'udp port 443'
# tunnel side: the inner tuples appear after decapsulation
tcpdump -ni tun0

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

การส่งต่อ NAT เป็นของผู้รับฟัง ไม่ใช่แอปพลิเคชัน

เกตเวย์ที่โฮสต์เองหลัง IPv4 NAT ต้องการการแปลขาเข้าหนึ่งรายการ: ที่อยู่และพอร์ตสาธารณะถูกแมปไปยังผู้รับฟัง VPN ไม่ต้องมีกฎใดสำหรับ SSH, HTTPS หรือ DNS เพียงเพราะผู้ใช้อุโมงค์เข้าถึงบริการเหล่านั้น การเผยแพร่พอร์ตเหล่านั้นจะเปิดเผยบริการที่อุโมงค์ปกป้องอยู่แล้ว กฎการส่งต่ออธิบายความสามารถในการเข้าถึงของผู้รับฟัง ไม่ใช่สิทธิ์สำหรับสิ่งใดภายใน

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

นโยบายภายในคือที่ที่การเข้าถึงถูกตัดสินจริง

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

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

dig @10.40.0.53 app.corp.example
nc -vz 10.40.0.10 8443
ssh -p 2222 [email protected]

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

WireGuard ลากเส้นเดียวกัน

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

อนุญาตบริการในนโยบายอินพุตท้องถิ่นเมื่อมันทำงานบนโฮสต์เอง หรือในนโยบายการส่งต่อเมื่อมันอยู่หลังโฮสต์นั้น ความแตกต่างนี้ตัดสินว่าชุดกฎใดเห็นแพ็กเก็ต

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