OpenVPN ใช้ได้ที่บ้านแต่ใช้ไม่ได้ในเครือข่ายหนึ่ง: UDP หรือ TCP?

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

ขั้นตอนใดล้มเหลวบอกว่าการเปรียบเทียบใดสำคัญ

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

จับแพ็กเก็ตขณะลองใหม่ ไม่ใช่หลังจากนั้น บนไคลเอนต์ tcpdump -ni any udp port 1194 แสดงว่ามีคำตอบใดกลับมาหรือไม่ ทำซ้ำบนอินเทอร์เฟซ WAN ของเซิร์ฟเวอร์ที่คุณควบคุม ซึ่งเผยว่ามีแพ็กเก็ตเหล่านั้นไปถึงปลายทางไกลหรือไม่

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

การกรอง UDP กับการปิดพอร์ต

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

โปรไฟล์ TCP บนพอร์ต 443 เป็นวิธีแก้ปัญหาปกติ เพราะคล้ายกับการไหลของ HTTPS ทั่วไปและผ่านพอร์ทัล captive และตัวกรองขาออกส่วนใหญ่ได้ ต้องมีเงื่อนไขสองข้อ เซิร์ฟเวอร์ต้องฟังด้วย proto tcp-server และไคลเอนต์ต้องตรงกับ proto tcp-client และผู้ให้บริการต้องเผยแพร่ปลายทางทางเลือกนั้น การเขียนโปรไฟล์ UDP ที่ใช้งานได้ใหม่เพื่ออ้างว่าเป็น TCP 443 ไม่เกิดประโยชน์เมื่ออีกฝั่งไม่มีใครฟัง

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

โปรโตคอลเก่าเปรียบเทียบได้ไม่ดีในแกนนี้ PPTP ต้องใช้ TCP 1723 บวก GRE และ GRE เป็นโปรโตคอล IP 47 ไม่ใช่พอร์ต การส่งต่อพอร์ตทั่วไปจึงแสดงมันไม่ได้

เมื่อสวิตช์เป็นตัวทิ้งแพ็กเก็ต

สวิตช์ที่จัดการได้สามารถทิ้งทันเนลโดยเจตนา HPE และ Aruba บางรุ่นมีตัวควบคุมการป้องกันน้ำท่วม UDP ซึ่งบางครั้งติดป้ายว่า Prevent UDP Blat Attack ในส่วนความปลอดภัยขั้นสูง เมื่อตัวควบคุมนั้นทำงานอยู่ เซิร์ฟเวอร์หลังสวิตช์จะไม่ตอบอะไรเลย และไคลเอนต์ทุกตัวหมดเวลาในลักษณะเดียวกัน การปิดมันและบันทึกการกำหนดค่าที่ทำงานอยู่คือการซ่อมทั้งหมด แต่ต้องหลังจากการยืนยันว่าสวิตช์อยู่ในเส้นทางจริง ๆ

หลักฐานโต้แย้งคือสิ่งที่แยกการทิ้งของสวิตช์ออกจากการบล็อกของผู้ให้บริการ อ่านตัวนับอินเทอร์เฟซและบันทึกการป้องกันน้ำท่วมก่อนเปิดตั๋วกับ ISP เราเตอร์ผู้บริโภคที่มีการป้องกัน DoS หรือน้ำท่วมก็ล้มเหลวในรูปแบบเดียวกัน และกล่องกลางใด ๆ ที่มีเวลาว่าง UDP สั้นก็เช่นกัน การจับมือที่ไม่เคยเสร็จสิ้นบ่งชี้การทิ้ง ขณะที่ทันเนลที่ตายหลังความเงียบหลายนาทีบ่งชี้เวลาจำกัด

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

การทับซ้อนของที่อยู่ที่ดูเหมือนความล้มเหลว DNS

เครือข่ายการเข้าถึงที่กำหนดหมายเลขภายใน 10.0.0.0/8 อาจทับซ้อนกับพูลของทันเนล และตัวแก้ไขชื่อมักอาศัยอยู่ในพูลนั้น เมื่อแล็ปท็อปได้รับที่อยู่เช่น 10.184.178.50 พร้อมมาสก์ /8 บน Wi-Fi ปลายทาง 10.x ทุกตัวเป็นภายในตามนิยาม แพ็กเก็ตไปยัง 10.4.0.1 จึงไปที่ LAN ทันเนลยังทำงานอยู่ และการแก้ชื่อล้มเหลว

ip addr เผยการทับซ้อนในพริบตา และ ip route get 10.4.0.1 แสดงว่าแพ็กเก็ตจะถูกส่งไปที่ใดจริง ๆ เพราะอาการที่มองเห็นคือความล้มเหลวของตัวแก้ไขชื่อ สิ่งนี้จึงมักอยู่รอดผ่านการเปลี่ยน DNS หลายรอบ

กำหนดหมายเลขพูลใหม่หรือเก็บเครือข่ายการเข้าถึงนั้นไว้นอกขอบเขต ไม่มีการตั้งค่าฝั่งไคลเอนต์ใดฟื้นจากการทับซ้อน

การเลือกระหว่างเส้นทางสำรอง TCP กับการแก้เส้นทาง

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

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