เราเตอร์ LAN กับไคลเอนต์ VPN: สองอุปกรณ์ สองตารางเส้นทาง

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

วาดสองฮอปก่อนแตะเส้นทาง

ลองใช้ผังตัวอย่าง: โฮสต์ LAN ที่192.168.50.0/24เราเตอร์ปกติที่192.168.50.1ไคลเอนต์เฉพาะที่192.168.50.15และ LAN ปลายทางไกลที่10.60.0.0/24ซึ่งเข้าถึงได้เฉพาะผ่านอุโมงค์ที่ไคลเอนต์นั้นถืออยู่ ช่วงส่วนตัวทั้งสองไม่ทับซ้อนกัน และอุโมงค์มีแผนที่อยู่ของตนเอง

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

ขั้นที่ 1: หันเราเตอร์ไปที่ไคลเอนต์ ไม่ใช่ที่อุโมงค์

บนเราเตอร์ LAN เพิ่มเส้นทางปลายทางที่มีฮอปถัดไปเป็นที่อยู่ LAN ของไคลเอนต์:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

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

ตรวจสอบคำตอบของคำสั่งที่สอง ถ้ารายงานไคลเอนต์เป็น gateway และอินเทอร์เฟซ LAN เป็น device แสดงว่าฮอปแรกถูกต้อง และงานที่เหลืออยู่บนเครื่องอีกเครื่อง

ขั้นที่ 2: ให้ไคลเอนต์มีเส้นทางของตนเองทางฝั่งอุโมงค์

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

ดูก่อนเพิ่มสิ่งใด:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

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

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

ขั้นที่ 3: อนุญาตการส่งต่อและเลือกเส้นทางขากลับ

การรับและการส่งต่อเป็นสิทธิ์ที่ต่างกันnet.ipv4.ip_forward=1บนไคลเอนต์อนุญาตการผ่านในระดับเคอร์เนล และกฎไฟร์วอลล์ยังต้องอนุญาตระหว่างอินเทอร์เฟซ LAN กับอุโมงค์ กฎที่อนุญาตการเข้าถึงหน้าจัดการของไคลเอนต์เองจะไม่อนุญาตการผ่านไปยัง LAN ปลายทางไกล และความแตกต่างนี้ง่ายที่จะมองข้ามเมื่อโฮสต์เดียวกันตอบ ping ในเครื่อง

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

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

ขั้นที่ 4: ทำให้การตัดสินใจทั้งสองคงอยู่ แล้วทดสอบเส้นทางจริง

ทุกเส้นทางมีเจ้าของ และเจ้าของคือการกำหนดค่าที่สร้างใหม่เมื่อบูตหรือเมื่อเชื่อมต่อใหม่ บนเราเตอร์อาจเป็นรายการเส้นทางแบบคงที่ บนไคลเอนต์อาจเป็นโปรไฟล์ VPN, NetworkManager หรือ systemd-networkd ตรวจสอบโดยเชื่อมต่ออุโมงค์ใหม่และรีบูตไคลเอนต์ แล้วอ่านตารางอีกครั้งแทนการเชื่อมการแก้ไข

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

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