ไคลเอนต์ VPN ไปถึงเซิร์ฟเวอร์แต่ไม่ถึง LAN: แก้อย่างไร?

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

ก่อนอื่น ยืนยันว่าทิศทางไหนเสีย

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

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

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

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

คำถามข้อหนึ่ง: คุณแก้ไขเราเตอร์ของ LAN ปลายทางได้หรือไม่

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

มันล้มเหลวอย่างเงียบ ๆ ในวันที่มีคนเปลี่ยนพูล จดค่าไว้ครั้งเดียวและถือว่าการแก้ในที่ใดที่หนึ่งจากสามที่คือการแก้ทั้งสามที่

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

คำถามข้อสอง: LAN หยุดเห็นที่อยู่ของไคลเอนต์ได้หรือไม่

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

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

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

คำถามข้อสาม: เซิร์ฟเวอร์เองเป็นไคลเอนต์ของอุโมงค์อื่นหรือไม่

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

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

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

จากนั้นตรวจสอบทั้งสองทิศทางและทั้งสองขนาด

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

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

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