ทราฟฟิกทางเดียวหลังปิด SNAT ของซับเน็ต Tailscale

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

SNAT ซ่อนอะไรไว้

เมื่อ SNAT เปิดอยู่ เราเตอร์จะเขียนที่อยู่ต้นทางใหม่เป็นที่อยู่ LAN ของตนเองก่อนส่งต่อไปยังซับเน็ต ปลายทางจึงตอบกลับไปยังโฮสต์ที่รู้วิธีเข้าถึงอยู่แล้วและไม่ต้องกำหนดค่าอย่างอื่นเพิ่ม เมื่อปิด ที่อยู่ต้นทางเดิมยังคงอยู่ และปลายทางจะเห็นที่อยู่ภายในช่วง overlay แทนที่จะเป็นเพื่อนบ้านบนสายของตนเอง ที่อยู่นั้นมีจริงและกำหนดเส้นทางได้ทั่วทั้ง tailnet แต่เข้าถึงไม่ได้จาก LAN ผ่านเกตเวย์เริ่มต้น สวิตช์ที่บันทึกไว้คือ --snat-subnet-routes=false ซึ่งใช้กับเราเตอร์ซับเน็ต Linux เอง

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

เส้นทางกลับอยู่ได้ที่ใด

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

ip route add 100.64.0.0/10 via 192.168.1.10
ip route get 100.64.0.5

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

การอ่านความล้มเหลวเป็นทราฟฟิกทางเดียว

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

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

sudo tcpdump -ni any host 100.64.0.5
ip route get 100.64.0.5

ที่อยู่จริงคุ้มค่ากับเส้นทางหรือไม่

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

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

ไฟร์วอลล์ การบันทึก และบทบาทคู่

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

sudo nft list ruleset | grep -n '100\.64'
sudo iptables-save | grep -n '100\.64'

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