ไคลเอนต์ OpenVPN ไปถึงเซิร์ฟเวอร์แต่ไม่ถึงโฮสต์ใน LAN: รายการตรวจสอบ

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

ขั้นแรก: ดูการตัดสินใจเลือกเส้นทางของไคลเอนต์

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

ip route get 192.168.50.10

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

บน Windows คำถามเดียวกันมีคำสั่งอื่น Find-NetRoute -RemoteIPAddress 192.168.50.10 พิมพ์อินเทอร์เฟซและฮอปถัดไปที่สแต็กจะเลือก และ route print -4 แสดงว่าคำนำหน้าที่ถูกดันมีอยู่จริงหรือไม่

ขั้นที่สอง: ยืนยันว่าเซิร์ฟเวอร์จะส่งต่อแพ็กเก็ต

ถ้าเส้นทางฝั่งไคลเอนต์ถูกต้อง แพ็กเก็ตจะไปถึงเซิร์ฟเวอร์ และเซิร์ฟเวอร์ต้องยอมส่งต่อ การตั้ง sysctl net.ipv4.ip_forward ให้คืนค่า 1 คือจุดตรวจแรก และการตั้งด้วย echo 1 > /proc/sys/net/ipv4/ip_forward จะอยู่ได้ถึงการรีบูตครั้งถัดไป ซึ่งเป็นเหตุผลที่อาการเดิมกลับมาอีกหลายสัปดาห์ให้หลัง

จดไว้ในที่ที่รอดจากการรีสตาร์ต:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

จุดตรวจที่สองคือตารางฟิลเตอร์ โฮสต์ที่ติดตั้ง Docker มักมีนโยบาย FORWARD เป็น DROP และอุโมงค์ก็สืบทอดการตัดสินใจนั้น iptables -L FORWARD -v -n แสดงทั้งนโยบายและตัวนับแพ็กเก็ต ถ้านโยบายเป็น DROP การส่งต่อต้องมีสิทธิ์ชัดเจนสำหรับทิศทางจากอุโมงค์ไปยัง LAN และอีกสิทธิ์หนึ่งสำหรับขากลับ

ขั้นที่สาม: ติดตามแพ็กเก็ตออกไปยัง LAN แล้วมองหาคำตอบ

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

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

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

ขั้นที่สี่: เลือกระหว่างการแปลที่อยู่กับการเพิ่มเส้นทางขากลับ

การแก้สองแบบปิดช่องโหว่นี้ และทางเลือกนี้มีผลเกินกว่าว่า ping จะทำงานหรือไม่ การแปลต้นทางทำให้เซิร์ฟเวอร์กลายเป็นผู้ส่งที่ดูเหมือนต้นทางจริง:

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

จำกัดกฎให้แคบลงที่พูลและอินเทอร์เฟซ LAN แล้วทำให้ถาวร ไม่อย่างนั้นการโหลดไฟร์วอลล์ครั้งถัดไปจะลบการแก้ไขของคุณอย่างเงียบ ๆ ราคาที่ต้องจ่ายคือตัวตน ทุกไคลเอนต์จะดูเหมือนเซิร์ฟเวอร์ VPN ในบันทึกของ LAN และในกฎการเข้าถึง และ per-client policy becomes guesswork

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

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

ปิดวงจากฝั่งไคลเอนต์ ไม่ใช่ฝั่งเซิร์ฟเวอร์ เชื่อมต่อบริการจริงบนโฮสต์ใน LAN แล้วยืนยันว่าตัวนับการแปลขยับด้วย iptables -t nat -L POSTROUTING -v -n เพราะกฎที่ไม่มีแพ็กเก็ตคือกฎที่ไม่เคยตรงเงื่อนไข conntrack -L -s 10.8.0.5 แสดงโฟลว์และสถานะของมันเมื่อคุณต้องการหลักฐานว่าทิศทางขากลับถูกติดตาม

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