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

เราเตอร์ส่งต่ออุโมงค์ โฮสต์ตัดสินแพ็กเก็ต

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

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

ผู้รับฟังแบบไวลด์การ์ดไม่ใช่บริการสาธารณะ

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

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

ss -lntp "sport = :22"
LISTEN 0 4096 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=812,fd=3))
LISTEN 0 4096 10.8.0.6:22 0.0.0.0:* users:(("sshd",pid=812,fd=4))

ระบุการจัดวางที่อาจไปถึงพอร์ตได้

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

ArrangementWhat reaches the portWhere the decision lives
Another permitted VPN peerA packet from the same tunnel subnetGateway forwarding policy and host input rules
A deliberate public forwardTraffic the gateway publishes on purposeGateway service definition
A subnet routed behind the gatewayClient traffic from the far sideGateway route and host input rules

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

จำกัดบริการให้อยู่ในเส้นทางที่คุณตั้งใจ

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

nft add rule inet filter input iifname "tun0" ip saddr 10.8.0.0/24 tcp dport 22 accept
nft list chain inet filter input

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

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

ยอมรับการแก้ไขด้วยความสำเร็จหนึ่งครั้งและการปฏิเสธหนึ่งครั้ง

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

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

บทความที่เกี่ยวข้อง