กำหนดเส้นทางระหว่าง LAN ส่วนตัวก่อนเพิ่ม NAT อีกชั้น

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

สามเงื่อนไขที่ตัดสินการออกแบบ

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

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

การออกแบบเรียบง่ายชนะก็ต่อเมื่อทั้งสามข้อชี้ไปทางเดียวกัน เมื่อข้อใดข้อหนึ่งล้มเหลว ให้แก้เงื่อนไขนั้นอย่างชัดเจนแทนที่จะกลบด้วยการแปลแอดเดรส เพราะ NAT ซ่อนความล้มเหลวแทนที่จะแก้ไข

สร้างแผนเส้นทางบนเครือข่ายทรานสิต

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

ไฟร์วอลล์ A ให้บริการ 10.30.0.0/24 และไฟร์วอลล์ B ให้บริการ 10.40.0.0/24 โดยมีแอดเดรสทรานสิตสองตัวอยู่ใน 192.0.2.0/24 โฮสต์ใน LAN แต่ละเครื่องยังใช้ไฟร์วอลล์ท้องถิ่นเป็นเกตเวย์ สถานะใหม่จึงมีเพียงเส้นทางเดียวในแต่ละฝั่ง บนไฟร์วอลล์ที่ใช้ Linux แผนเดียวกันมีหน้าตาแบบนี้ และต้องเปิดการส่งต่อ ไม่เช่นนั้นเส้นทางจะถูกแก้ไขแต่แพ็กเก็ตจะถูกทิ้ง

sysctl -w net.ipv4.ip_forward=1
ip route add 10.40.0.0/24 via 192.0.2.20 dev eth1
ip route get 10.40.0.15
traceroute -n 10.40.0.15

แยกการกรองออกจากการแปล

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

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

iptables -t nat -S POSTROUTING
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni eth1 -c 5 host 10.40.0.15

เมื่อ NAT คือคำตอบที่ซื่อตรง

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

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

เมื่อตัวทรานสิตเองคือสมมติฐานที่ผิด

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

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