proto udp หรือ tcp-client: เซิร์ฟเวอร์ของคุณได้ยินแบบไหน?

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

อ่านทรานสปอร์ตที่การเชื่อมต่อที่เลือกใช้

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

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

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

grep -nE '^(remote|proto)\b' client.ovpn

UDP และ TCP ไม่ใช่การตั้งค่าความเร็ว

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

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

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

tcp-client หมายถึงอะไรจริง ๆ

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

การตรงกันหมายถึงทั้งสองฝั่งตกลงเรื่องทรานสปอร์ต ไม่ใช่การแชร์สตริงเดียวกัน

grep -nE '^proto\b' /etc/openvpn/server/server.conf
ss -lntp | grep openvpn

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

เมื่อนำเข้าโปรไฟล์ได้แต่ไม่เคยเชื่อมต่อ

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

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

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

บันทึกทรานสปอร์ตที่ใช้งานได้

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

ไม่เช่นนั้นคนถัดไปที่เจอการหมดเวลาจะลองการทดลองเดิมในทิศทางตรงข้าม และอาจ เปลี่ยนเซิร์ฟเวอร์ที่ดีอยู่แล้ว

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