ไคลเอนต์ PPTP บน DD-WRT มองไม่เห็นกัน: ห้าขั้นตอนตรวจสอบ

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

ขั้นที่หนึ่ง: /32 ไม่ใช่บั๊ก

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

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

ขั้นที่สอง: อ่านค่าบนหน้าต่างเซิร์ฟเวอร์ PPTP

การตั้งค่าที่สำคัญทั้งหมดอยู่ที่ บริการ, VPN, เซิร์ฟเวอร์ PPTP เปิดเซิร์ฟเวอร์ ตั้งที่อยู่เซิร์ฟเวอร์เป็นที่อยู่ LAN ของเราเตอร์ และเก็บช่วงไคลเอนต์ไว้นอกพูล DHCP เพื่อให้ไคลเอนต์ที่หมุนสายเข้ามาและเครื่องที่ต่อสายไม่ได้รับที่อยู่เดียวกัน ใต้ CHAP-Secrets ให้เพิ่มบรรทัดละหนึ่งบัญชีในรูปแบบ username * password * โดยไม่มีช่องว่างในชื่อ นำไปใช้ แล้วเชื่อมต่อด้วยโปรไฟล์ที่ระบุชื่อเราเตอร์และบัญชีใดบัญชีหนึ่งเหล่านั้น

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

ขั้นที่สาม: มองหาเส้นทางระหว่างเพียร์สองตัว

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

เส้นทางระดับโฮสต์สองเส้นไปยังอินเทอร์เฟซ ppp สองอันแยกกันคือรูปแบบที่คุณต้องการก่อนไปต่อ

ขั้นที่สี่: ดูลูกโซ่ FORWARD ไม่ใช่ INPUT

ทราฟฟิกระหว่างไคลเอนต์ถูกส่งต่อ ไม่ได้รับไว้ในเครื่อง จึงเป็นลูกโซ่ INPUT ที่ผิดที่ รัน iptables -L FORWARD -v -n แล้วมองหากฎดรอปที่จับอินเทอร์เฟซ PPP พร้อมตัวนับแพ็กเก็ตที่บอกว่ามีอะไรมาถึงลูกโซ่หรือไม่ นโยบายดรอปเริ่มต้นที่ไม่มีกฎยอมรับสำหรับทราฟฟิกอุโมงค์ให้อาการเดียวกับที่คุณเริ่มต้น: ไคลเอนต์แต่ละตัวอยู่คนเดียวก็ปกติดี อยู่ด้วยกันกลับมองไม่เห็นกัน

ถ้าปิงเล็ก ๆ ทำงานแต่การถ่ายโอนใหญ่ค้าง อุโมงค์กำลังถูกแบ่งส่วนไม่ใช่ถูกบล็อก PPTP บน PPP ปกติต้องการ MTU และ MRU ราว 1450 และการปล่อยไว้ที่ 1500 ทำให้ได้ลิงก์ที่ผ่านแฮนด์เชกแต่ล้มเหลวกับเพย์โหลดจริง

ขั้นที่ห้า: ตัดสินใจว่าการเข้าถึงอินเทอร์เน็ตควรทำอะไร

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

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