คุณควรใช้ SNAT กับการส่งต่อพอร์ตเข้าซับเน็ต VPN หรือไม่?

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

ทำไมคำตอบจึงไปอีกเส้นทาง

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

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

กฎต้นทางที่แคบพอจะไว้ใจได้

ทำให้เราเตอร์เป็นต้นทางที่โฮสต์ปลายทางตอบกลับ ในผังนี้ที่อยู่ WAN คือ 203.0.113.24 LAN คือ 192.168.88.0/24 ที่อยู่อุโมงค์ของเราเตอร์คือ 172.20.5.1 และบริการตอบที่ 172.20.5.40:8443 กฎด้านล่างจับแพ็กเก็ตหลังการแปลปลายทาง จึงระบุที่อยู่ที่แปลแล้วไม่ใช่ที่อยู่สาธารณะ ไม่มีอะไรในกฎขึ้นกับที่อยู่ของไคลเอนต์ และนั่นคือประเด็นทั้งหมด

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

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

เมื่อใดการมาสค์แบบครอบคลุมคือทางเลือกที่ซื่อสัตย์

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

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

ตรวจสอบตัวนับก่อนเผยแพร่

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

iptables -t nat -L POSTROUTING -v -n --line-numbers

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