อุโมงค์ขึ้นแล้ว แต่อินเทอร์เน็ตไม่มี: การส่งต่อหยุดตรงไหน

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

ยืนยันว่าทางออกสู่อินเทอร์เน็ตเคยเป็นดีไซน์ตั้งแต่แรกหรือไม่

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

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

ติดตามคำขอสาธารณะหนึ่งรายการ

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

ip route get 1.1.1.1
ip -4 addr show tun0
conntrack -L | grep 1.1.1.1
tcpdump -ni any host 1.1.1.1

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

ตรวจสอบการส่งต่อ เส้นทาง และการแปลที่อยู่

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

sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
nft list ruleset | grep -A6 forward
sysctl net.ipv4.conf.all.rp_filter

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

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

เส้นทางตอบกลับและตัวแก้ไขชื่อเป็นคำตอบที่ต่างกันสองอย่าง

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

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

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