ไม่มี PPTP passthrough: แก้ไขข้อผิดพลาด 807 ของ VPN บน Windows

การส่งต่อ TCP 1723 มักแก้ปัญหา PPTP ได้เพียงครึ่งแรกและทิ้งส่วนที่เหลือไว้เสีย Windows จึงยังคงคืนข้อผิดพลาด 807 เมื่อพยายามเชื่อมต่อ ความคิดต่อไปคือเพิ่มกฎสำหรับพอร์ต 47 และนั่นคือขั้นตอนที่ทำให้เสียเวลาทั้งบ่าย: GRE คือหมายเลขโปรโตคอลในส่วนหัว IP ไม่ใช่พอร์ตที่ตารางส่งต่อจะจับคู่ได้ จนกว่าเราเตอร์จะยอมผ่านโปรโตคอล 47 และผูกเข้ากับการเรียกเดียวกัน อุโมงค์ก็เริ่มไม่ได้ หัวข้อด้านล่างจะแยกสองช่องทางนี้แล้วทดสอบทีละอย่าง

ตารางพอร์ตไม่มีแถวสำหรับหมายเลขโปรโตคอล

PPTP ใช้การสนทนาสองอย่างที่ล้มเหลวต่างกัน ตัวหนึ่งบน TCP 1723 เริ่มการเรียก ส่งข้อมูลลิงก์ และฉีกมันทิ้งเมื่อผู้ใช้ตัดการเชื่อมต่อ ฝั่งเพย์โหลดทำงานภายใน GRE ซึ่งส่วนหัว IP ระบุด้วยหมายเลขโปรโตคอล 47 และภายในอุโมงค์นั้น PPP เจรจาลิงก์ขณะที่ MS-CHAPv2 ตรวจสอบข้อมูลรับรอง

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

Windows รายงานอะไรเมื่อเส้นทางข้อมูลตาย

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

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

ทำไมไคลเอนต์ตัวที่สองจึงทำให้อุโมงค์ที่ใช้งานได้พัง

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

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

พิสูจน์ว่าครึ่งไหนล้มเหลว

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

Test-NetConnection vpn.example.com -Port 1723
rasdial "Work VPN"

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

tcpdump -ni any proto 47

สิ่งที่เทียบเท่าใน Wireshark คือตัวกรองการแสดงผล ip proto 47 ซึ่งส่งต่อให้คนที่ไม่ถนัด shell ได้ง่ายกว่า GRE ที่มาถึงโดยไม่มีสิ่งใดออกไปตอบกลับหมายถึงเส้นทางขากลับต้องได้รับการซ่อม

อะไรแก้ข้อผิดพลาดได้จริง

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

/ip firewall filter add chain=forward protocol=gre action=accept
/ip firewall filter print where protocol=gre

การแทนที่ PPTP คือทางเลือกอีกทางและมักถูกกว่า เราเตอร์ที่ยุติ VPN เองหลีกเลี่ยง NAT ซ้อนสำหรับไคลเอนต์ขาเข้า และโปรโตคอลที่ NAT ตามพอร์ตจัดการอยู่แล้วไม่จำเป็นต้องมี passthrough เลย: OpenVPN บน UDP, SSTP บน TCP 443 หรือ L2TP/IPsec กับ NAT-T ที่ห่อ ESP ไว้ใน UDP 4500 PPTP ยังพึ่งพา MS-CHAPv2 ซึ่งจุดอ่อนที่มีการบันทึกไว้ทำให้เป็นตัวเลือกที่ไม่ดีสำหรับการติดตั้งใหม่แม้ข้อผิดพลาดจะหายแล้ว

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