ฮอปถัดไปในเส้นทาง VPN: ทำไมเกตเวย์ต้องเข้าถึงได้ในเครื่อง

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

คู่มือนี้ครอบคลุมกรณีปกติ คือแล็ปท็อปบน 192.168.20.0/24 เกตเวย์ VPN ที่มีแอดเดรส LAN เป็น 192.168.20.5 และเครือข่ายปลายทางไกล 10.70.0.0/24 ที่อยู่หลังเกตเวย์นั้น คำสั่งทั้งหมดด้านล่างถือว่าคุณอยู่บนแล็ปท็อป เว้นแต่จะระบุไว้เป็นอย่างอื่น

สองแอดเดรส หนึ่งเส้นทาง

รายการที่ตั้งใจไว้คือ 10.70.0.0/24 via 192.168.20.5 คำนำหน้าบอกว่าแพ็กเก็ตไปที่ใด แอดเดรส via บอกว่าใครพามันไปที่นั่น เคอร์เนลปฏิเสธที่จะติดตั้งเส้นทางที่มันเข้าถึงเกตเวย์ไม่ได้ผ่านอินเทอร์เฟซที่คุณระบุ และการปฏิเสธนั้นคือประเด็นทั้งหมด: ฮอปถัดไปที่ต้องอาศัยอุโมงค์จึงจะเข้าถึงได้ ไม่สามารถเป็นฮอปถัดไปที่สร้างอุโมงค์ได้

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

ฮอปถัดไปผูกมัดเกตเวย์ไว้กับอะไร

การติดตั้งเส้นทางบนแล็ปท็อปตัดสินเพียงการส่งต่อครั้งแรก หลังจากนั้นเกตเวย์ต้องมีเส้นทางของตัวเอง คือเปิดการส่งต่อ มีเส้นทางอุโมงค์สำหรับ 10.70.0.0/24 และนโยบายการเข้าถึงใด ๆ ที่กำหนดว่าใครใช้ได้ บน Linux นั่นคือ net.ipv4.ip_forward=1 พร้อมเส้นทางอุโมงค์ ไฟร์วอลล์ที่อยู่ข้างหน้าต้องมีกฎที่อนุญาตให้ฟลักซ์ที่ถูกส่งต่อผ่านได้

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

ตรวจสอบการค้นหาจากโฮสต์ที่ส่ง

ถามเคอร์เนลว่าจะเลือกฮอปถัดไปใด แล้วอ่านอินเทอร์เฟซในคำตอบ:

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

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

จากนั้นทำการทดสอบซ้ำจากตำแหน่งที่ถูกต้อง คำขอที่สร้างบนเกตเวย์ใช้แอดเดรสต้นทางของเกตเวย์เอง ซึ่งอาจซ่อนเส้นทางขากลับที่หายไปหรือนโยบายที่อนุญาตเฉพาะบางต้นทาง คู่มือ ip-route แยกปลายทาง เกตเวย์ และการแทนที่ onlink ออกจากกัน และการแทนที่นั้นคุ้มค่าที่จะเข้าใจก่อนใช้งาน

อย่าใช้ onlink เพื่อแสร้งว่าสามารถเข้าถึงได้

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

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

อุโมงค์แบบจุดต่อจุดไม่ใช่ Ethernet

อุปกรณ์อุโมงค์ไม่ได้ทำ ARP และมักไม่มีซับเน็ตของเพื่อนบ้านที่มีความหมาย เส้นทางของมันมักมีลักษณะเป็น 10.70.0.0/24 dev tun0 โดยไม่มี via เลย เพราะเพียร์เป็นจุดปลายอีกด้านเดียว การคัดลอก via แบบ LAN ลงในตารางนั้นจะสร้างเส้นทางที่เคอร์เนลอาจปฏิเสธ หรือแย่กว่านั้น คือชี้ไปยังแอดเดรสที่เพียร์ไม่เคยตอบ

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

เพิ่ม ยืนยัน ย้อนกลับ

การเปลี่ยนแปลงทั้งหมดคือสามคำสั่งและการตรวจสอบหนึ่งครั้ง และควรเขียนไว้ตามลำดับนั้น:

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

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