TCP 443 ช่วยได้จริงหรือ? ก็ต่อเมื่อเซิร์ฟเวอร์ฟังอยู่ที่นั่น
โปรไฟล์ TCP คือทางสำรอง ไม่ใช่การพรางตัว ตรวจสอบว่าเซิร์ฟเวอร์ฟังอยู่ที่พอร์ตนั้น แล้วชั่งน้ำหนักต้นทุนของ TCP สองชั้นกับการเข้าถึงไม่ได้
TCP 443 เป็นทางสำรองที่มีเงื่อนไขเบื้องต้น ไม่ใช่การพรางตัวที่พาโครงข่ายท่อลอดผ่านตัวกรองใด ๆ มันช่วยได้เมื่อผู้ให้บริการเผยแพร่ตัวฟัง TCP บนพอร์ตนั้นอยู่แล้ว และเส้นทางทนต่อการเชื่อมต่อที่เปิดค้างไว้เป็นชั่วโมง ๆ มันล้มเหลว โดยปกติในรูปของการหมดเวลา เมื่ออย่างใดอย่างหนึ่งในสองอย่างนั้นขาดไป และการหมดเวลาก็มักไม่บอกว่าขาดอย่างไหน การตัดสินใจว่าจะเปลี่ยนหรือไม่ต้องใช้สามคำถาม และมีเพียงคำถามเดียวที่เกี่ยวกับหมายเลขพอร์ต
หมายเลขพอร์ตไม่ใช่คำสัญญาของการขนส่ง
พอร์ตตั้งชื่อจุดปลายทาง TCP เปลี่ยนมันให้เป็นลำธารไบต์ที่มีลำดับ OpenVPN ตัดสินใจว่าอะไรเดินทางอยู่ภายในลำธารนั้น เว็บเซิร์ฟเวอร์บนหมายเลขเดียวกันใช้การจัดวางแอปพลิเคชันที่ต่างกันโดยสิ้นเชิง การใช้พอร์ต 443 ร่วมกันจึงทำให้ทั้งสองดูคล้ายกันสำหรับตัวกรอง และไม่มากไปกว่านั้น หมายเลขเป็นเพียงเบาะแสที่ตัวกรองอ่าน ไม่ใช่คุณสมบัติที่เปลี่ยนสิ่งที่แพ็กเก็ตบรรจุ การถือว่าทั้งสองเป็นสิ่งเดียวกันเพราะใช้พอร์ตร่วมกันคือความผิดพลาดที่อยู่เบื้องหลังความสับสนส่วนใหญ่ที่นี่
อุปกรณ์กลางทาง ตัดสินใจแบบอนุญาตหรือปฏิเสธง่าย ๆ เกี่ยวกับพอร์ต หลายตัวตรวจไบต์แรก บางตัวตรึงปลายทาง และบางตัวรีเซ็ตการเชื่อมต่อที่เปิดค้างไว้นานเกินไป นี่คือเหตุผลว่าทำไมโปรไฟล์เดียวกันจึงทำงานได้จากเครือข่ายหนึ่งและหมดเวลาจากอีกเครือข่ายหนึ่ง และนี่คือเหตุผลที่ทางสำรองควรถูกทดสอบในฐานะตัวเลือกที่รองรับ ไม่ใช่เชื่อถือเป็นคำสัญญา เมื่อตัวกรองตรวจสอบการรับส่งข้อมูล หมายเลขพอร์ตเป็นเพียงสิ่งแรกที่มันมอง
ยืนยันตัวฟังก่อนแตะโปรไฟล์
เซิร์ฟเวอร์ต้องถูกกำหนดค่าให้ใช้ TCP บนพอร์ต และโปรไฟล์ไคลเอนต์ต้องขอการขนส่งเดียวกัน การเขียนโปรไฟล์ UDP ใหม่ให้ขอ TCP ไม่ได้สร้างตัวฟังขึ้นมา และการหมดเวลาที่ตามมาจึงแยกไม่ออกจากไฟร์วอลล์ที่โยนพอร์ตทิ้ง ดาวน์โหลดโปรไฟล์ TCP ของผู้ให้บริการเองเมื่อมี เพราะบางบริการเผยแพร่จุดปลายทางและค่าการระบุตัวตนแยกต่างหากสำหรับแต่ละการขนส่ง การแก้ไขด้วยมือเหมาะกับการทดสอบที่มีการควบคุม และเป็นวิธีที่ไม่ดีในการเดาการกำหนดค่าที่ผู้ให้บริการตั้งใจไว้
ทั้งสองด้านของการจับคู่นั้นปรากฏในการกำหนดค่า และตัวเลือกการเชื่อมโยงของโครงการ OpenVPN บันทึกทั้งสองรูปแบบ คู่ที่เล็กที่สุดมีลักษณะเช่นนี้
# server: accept TCP on this port
proto tcp-server
port 443
# client: request the same transport
proto tcp
remote vpn.example.com 443เงื่อนไขสามข้อตัดสินว่าทางสำรองคุ้มค่าหรือไม่
เงื่อนไขแรกคือผู้ให้บริการเสนอการขนส่งนั้นเลย หากไม่มีข้ออื่นก็ไม่สำคัญ ข้อที่สองคือเส้นทางรักษาเซสชันอายุยาวให้ยังมีชีวิต เพราะบางเครือข่ายรีเซ็ตการเชื่อมต่อที่เปิดค้างไว้แทนที่จะปิดกั้นพอร์ตทั้งหมด ข้อที่สามคือทางสำรองเป็นข้อยกเว้นที่ตั้งใจหรือเป็นทางแก้ชั่วคราวที่ซ่อนข้อบกพร่องซึ่งคุณยังไม่ได้แก้ไข
ทุกเงื่อนไขมีการตรวจสอบที่ราคาถูก ความล้มเหลวในข้อใดข้อหนึ่งจะดูเหมือนกันจากฝั่งไคลเอนต์
| Condition | How to check it | What a failure decides |
|---|---|---|
| The server offers TCP | The operator's profile list, or a listening-socket check on the server | No client-side edit can help |
| The path keeps long sessions | A test connection left open for an hour | Reconnects will look like server faults |
| The fallback is deliberate | A change record naming the UDP fault | The underlying fault stays invisible |
ก่อนเปรียบเทียบการขนส่ง ให้ทำการลงชื่อเข้าใช้พอร์ทัลแบบกักขังให้เสร็จ เครือข่ายที่ยังไม่รับอุปกรณ์ของคุณจะปิดกั้นทั้งสองการขนส่ง และการเปรียบเทียบก็จะวัดพอร์ทัลแทนที่จะวัดอุโมงค์ ลงชื่อเข้าใช้ ยืนยันว่าการท่องเว็บปกติทำงาน และหลังจากนั้นจึงเริ่มการทดสอบ
ต้นทุนที่คุณยอมรับ: TCP ซ้อนอยู่ใน TCP
TCP ส่งส่วนที่สูญหายซ้ำและรักษาลำดับของมัน เมื่อแอปพลิเคชันที่ใช้ TCP ด้วยทำงานอยู่ภายในอุโมงค์ TCP ชั้นการกู้คืนสองชั้นตอบสนองต่อการสูญเสียเดียวกัน และปฏิสัมพันธ์นั้นเองที่ทำให้อุโมงค์รู้สึกช้าบนเส้นทางที่มีการสูญเสีย อาการคือความหน่วงและการสั่นไหวมากกว่าความล้มเหลวที่สะอาด ซึ่งทำให้ง่ายต่อการโทษปลายทางไกล วัดจากฝั่งไคลเอนต์บนทั้งสองการขนส่งก่อนสรุป
UDP หลีกเลี่ยงการซ้อนนี้ และนั่นคือเหตุผลหลักที่ผู้ให้บริการชอบมันและเสนอก็ TCP เพียงเป็นทางเลือก การเชื่อมต่อ TCP ที่มั่นคงยังมีประโยชน์มากกว่าการเชื่อมต่อ UDP ที่เข้าถึงไม่ได้ ดังนั้นการเปรียบเทียบจึงอยู่ระหว่างต้นทุนจริงสองอย่าง ไม่ใช่ระหว่างตัวเลือกที่ดีกับตัวเลือกที่แย่ รักษาอุปกรณ์และเครือข่ายการเข้าถึงให้คงที่ขณะเปรียบเทียบ มิฉะนั้นผลลัพธ์จะอธิบายตัวแปรผิดตัว
คุณลักษณะไคลเอนต์บางอย่างมีเอกสารสำหรับการขนส่งเดียวเท่านั้น โปรไฟล์สำรองจึงอาจทิ้งพฤติกรรมที่คุณพึ่งพาอยู่โดยไม่ส่งเสียง การอ่านข้อกำหนดการขนส่งของตัวเลือกก่อนถือว่าโปรไฟล์ TCP เป็นการสลับตรง ๆ
ข้อบกพร่องที่การขนส่งอื่นไม่แตะต้อง
ใบรับรองที่หมดอายุยังต้องตรวจสอบนาฬิกาหรือต่ออายุ และบัญชีที่ถูกปฏิเสธยังต้องใช้ข้อมูลรับรองที่ถูกต้อง รักษาการตรวจสอบตัวตนของเซิร์ฟเวอร์ที่ผู้ให้บริการมอบให้ เพราะหมายเลขพอร์ตที่คุ้นเคยไม่ได้ยืนยันตัวใครเลย พอร์ตที่ตอบสนองบอกเพียงว่ามีบางสิ่งกำลังฟังอยู่
หากอุโมงค์ขึ้นมาแต่ปลายทางยังล้มเหลว ปัญหาที่เหลือคือการกำหนดเส้นทางหรือการแปลงชื่อหลังการเชื่อมต่อ ไม่ใช่การขนส่ง ตามเส้นทางนั้นแทนการวนเปลี่ยนพอร์ต เพราะนั่นคือวิธีที่บ่ายหนึ่งหายไป โปรไฟล์บอกคุณว่าควรลองการขนส่งใด มันไม่เคยบอกว่าทำไมเส้นทาง UDP จึงล้มเหลว