ไคลเอนต์ VPN แบบเราเตอร์เข้าถึงเซิร์ฟเวอร์ได้แต่เข้าถึงโฮสต์ใน LAN ไม่ได้

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

ตามคำตอบ ไม่ใช่ตามคำขอ

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

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

วางเส้นทางกลับไว้ที่ที่โฮสต์มอง

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

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

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

ทำไม Source NAT ดูเหมือนจะแก้ได้

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

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

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

เส้นทางบนคลาวด์ต้องมีการตั้งค่าสามอย่าง

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

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

ทำการตรวจสอบตามลำดับนี้

ยืนยันการส่งต่อและนโยบายการกรองก่อนจะโทษการกำหนดเส้นทาง เพราะโฮสต์ที่ไม่ยอมส่งต่อก็ล้มเหลวแบบเงียบเหมือนกัน จากนั้นอ่านการตั้งค่าเส้นทางย้อนกลับที่มีผลบนอินเทอร์เฟซที่พาอุโมงค์ เพราะตัวกรองที่เข้มงวดอาจทิ้งคำตอบที่มาจากทิศทางที่ไม่คาดคิด

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

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

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