เว็บเซิร์ฟเวอร์หายไปเมื่อไคลเอนต์ VPN เชื่อมต่อ

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

อาการ: คำขอเข้า คำตอบออกผิดประตู

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

ยืนยันได้ด้วยการดูว่าคำตอบไปที่ใด ไม่ใช่ดูว่าคำขอมาถึงอย่างไร

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

สองเส้นทางเริ่มต้นและการตัดสินใจกำหนดเส้นทางหนึ่งครั้ง

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

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

อุโมงค์ทำงานอย่างถูกต้องตลอดเวลา มีคำสั่งให้มัน บรรทุกเส้นทางเริ่มต้นและมันทำเช่นนั้นเป๊ะ

ซ่อมเส้นทางขากลับโดยไม่ทำให้อุโมงค์แตก

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

เลือกตามสิ่งที่โฮสต์ต้องทำ ไม่ใช่ตามตัวอย่างที่คุณเจอก่อน

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

ip rule show
ip route get 203.0.113.9 from 192.0.2.44

เมื่อโฮสต์กำหนดเส้นทางให้ LAN ที่อยู่ข้างหลังด้วย

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

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

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