ทำไมโปรไฟล์ OpenVPN ใช้งานได้ที่บ้านแต่ล้มเหลวในโรงแรม

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

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

ข้อเท็จจริงเครือข่ายสี่ข้อเปลี่ยนไปตามสถานที่

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

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

ข้อที่สามคือการกรองการขนส่ง เครือข่ายที่ต้องการอนุญาตเฉพาะการท่องเว็บจะปล่อย TCP 443 ไปยังปลายทางใดก็ได้และทิ้งเกือบทุกอย่างที่เหลือ รวมถึง UDP

ข้อที่สี่คือการกำหนดที่อยู่ ซับเน็ตภายในอาจทับซ้อนกับเครือข่ายหลังอุโมงค์ หรือลิงก์ขาออกอาจไม่มีเส้นทาง IPv4 ที่ใช้ได้เลย

การแปลงชื่อกับพอร์ทัลเข้าสู่ระบบ

แทนที่ชื่อโฮสต์ในโปรไฟล์ด้วยที่อยู่ตัวเลขของเซิร์ฟเวอร์แล้วลองใหม่ ถ้า IP เชื่อมต่อได้แต่ชื่อไม่ได้ ปัญหาอยู่ที่การแปลงชื่อ และตัวโปรไฟล์เองก็ปกติดี

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

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

การกรองการขนส่ง: UDP ก่อน แล้ว TCP 443 เป็นทางสำรอง

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

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

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

การชนกันของที่อยู่และลิงก์ขาออกที่ไม่มี IPv4

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

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

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

อาการหลังอุโมงค์ขึ้นแล้ว

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

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