MikroTik PPTP หลุดบ่อย? แก้เส้นทางไปยังเซิร์ฟเวอร์

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

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

อาการ: เชื่อมต่อได้ ส่งทราฟฟิกได้ แล้วก็ตาย

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

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

ทำไมอุโมงค์จึงกลืนแพ็กเก็ตของตัวเอง

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

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

ปักหมุดที่อยู่เซิร์ฟเวอร์ไว้บน WAN

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

/ip route add dst-address=198.51.100.10/32 gateway=192.0.2.1 distance=10

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

หรือหยุดให้อุโมงค์ยึดเส้นทางเริ่มต้น

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

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

ตรวจสอบเป็นชั้น แล้วปิดช่องโหว่ด้านการจัดการ

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

/ip firewall nat add chain=srcnat out-interface=pptp-out1 action=masquerade

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

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