VPN บนเราเตอร์ทำงาน แต่ไคลเอนต์ LAN ไม่มีอินเทอร์เน็ต

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

อ่านความล้มเหลวจากโฮสต์ LAN

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

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

ทราฟฟิกในเครื่องและทราฟฟิกที่ส่งต่อนั้นต่างกัน

Linux และเฟิร์มแวร์เราเตอร์ส่วนใหญ่ปฏิบัติต่อแพ็กเก็ตที่เกิดจากตัวกล่องต่างจากแพ็กเก็ตที่ผ่านกล่องนั้น ห่วงโซ่ output มองเห็นชนิดแรก ห่วงโซ่ forward มองเห็นชนิดที่สอง และ นโยบายที่ปรับให้เข้ากับทราฟฟิกของเราเตอร์เองอาจปล่อยให้การส่งต่อไม่ถูกแตะต้อง.

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

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

เส้นทางย้อนกลับก็ต้องมีอยู่ด้วย

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

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

DNS ของไคลเอนต์อยู่ในบทตรวจเดียวกัน ตัวแก้ชื่อของเราเตอร์อาจตอบได้ ขณะที่ไคลเอนต์ที่ชี้ไปยังเซิร์ฟเวอร์อื่นไม่ได้รับอะไรเลย

ตรวจสอบหนึ่งโฟลว์ที่อนุญาตและหนึ่งโฟลว์ที่ถูกปฏิเสธ

หลังการแก้ไข ให้ทดสอบการเชื่อมต่อใหม่จากไคลเอนต์ ไม่ใช่เซสชันของเราเตอร์ที่มีอยู่ แล้วยืนยันว่าส่วนที่ไม่ควรใช้อุโมงค์ยังคงไม่ใช้มัน

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

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

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