PPTP ผ่านฮอตสปอต: TCP 1723 เป็นเพียงครึ่งเดียว

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

GRE คือโปรโตคอล IP 47 ไม่ใช่พอร์ต 47 ของ TCP หรือ UDP และความแตกต่างนี้อธิบายความสับสนส่วนใหญ่เกี่ยวกับไฟร์วอลล์

สองเส้นทาง หนึ่งการเชื่อมต่อ

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

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

ฮอตสปอตเพิ่มขอบเขตอีกสองแห่ง

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

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

อ่าน 807 เป็นการขัดจังหวะ ไม่ใช่คำตัดสิน

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

การทดสอบเบราว์เซอร์ที่สำเร็จบนฮอตสปอตพิสูจน์เพียงว่าเส้นทางแอปพลิเคชันธรรมดาทำงาน ไม่ได้บอกอะไรเกี่ยวกับ GRE

แยกขั้นตอนที่ล้มเหลวออกมา

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

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

สำหรับการเข้าถึงต่อเนื่อง ให้ตกลงการย้ายข้อมูลที่ได้รับการสนับสนุนกับเจ้าของ VPN รายการตรวจสอบจบด้วยการตัดสินใจไม่ใช่การเลี่ยงชั่วคราว