พอร์ตต้นทางของผู้ใช้กับตัวรับฟังของเซิร์ฟเวอร์ในโฟลว์ VPN
เปรียบเทียบหมายเลขพอร์ตสองตัวในอุโมงค์เดียว: ตัวรับฟังคงที่ของเซิร์ฟเวอร์และต้นทางชั่วคราวของผู้ใช้ และการแปลที่เราเตอร์วางอยู่ระหว่างกลาง
มีตัวเลขสองตัวปรากฏในบทสนทนาเดียวกัน และไม่มีตัวใดผิด บันทึกของเซิร์ฟเวอร์แสดงตัวรับฟังที่ให้บริการ แล็ปท็อปแสดงซ็อกเก็ตที่ส่งดาตาแกรม และเราเตอร์ที่อยู่ระหว่างกลางอาจเขียนตัวที่สองใหม่ตอนออกไป การเปรียบเทียบปลายทั้งสองของบทสนทนามีประโยชน์กว่าการเปรียบเทียบตัวเลข การเปรียบเทียบด้านล่างแยกตัวรับฟัง ซ็อกเก็ตของผู้ใช้ และต้นทางที่แปลแล้วออกจากกัน เพราะทั้งสามตอบคำถามต่างกัน
ตัวเลขสองตัวที่อธิบายปลายที่ตรงข้ามกัน
พอร์ตที่กำหนดค่าไว้ของเซิร์ฟเวอร์คือปลายทางที่ผู้ใช้เรียกหา มันถูกกำหนดโดยนโยบาย ปรากฏในโปรไฟล์ และต้องเปิดอยู่ฝั่งเซิร์ฟเวอร์ ส่วนพอร์ตต้นทางของผู้ใช้ถูกเลือกในเครื่อง โดยปกติมาจากช่วงชั่วคราว และมีไว้เพื่อให้คำตอบมีที่ลง มันอาจเปลี่ยนทุกครั้งที่เชื่อมต่อใหม่ และไม่มีสิ่งใดในการออกแบบที่ขึ้นกับความเสถียรของมัน
เราเตอร์ที่อยู่ระหว่างกลางอาจเขียนต้นทางนั้นใหม่เป็นแมปปิง 'NAT' ของตัวเอง นั่นคือเหตุผลที่หมายเลขซึ่งเห็นบนเซิร์ฟเวอร์มักไม่เกี่ยวข้องกับหมายเลขที่แล็ปท็อปเลือก
หมายเลขต้นทางเปลี่ยนที่ใดระหว่างทางออก
ลองตัวอย่าง IPv4 สมมติ: ผู้ใช้หลังเราเตอร์ที่แปลอยู่ เซิร์ฟเวอร์ที่มีตัวรับฟัง 'UDP' หนึ่งตัว และดาตาแกรมหนึ่งลูกที่ผ่านทั้งสองฝั่ง ตารางระบุแต่ละปลายและสิ่งที่เกิดขึ้นกับมัน แทนที่จะเล่นแพ็กเก็ตซ้ำที่จุดสังเกตสามจุด
| Endpoint | What stays fixed | What changes on reconnect | Who owns it |
|---|---|---|---|
| Server listener | The service port and the address the profile names | Nothing; the listener does not follow the client | The server operator |
| Client socket | The destination it dials | The local source port, chosen per socket | The client, or its operating system |
| Translated source | Usually the public address of the router | The port, and sometimes the address after a network switch | The NAT device or the upstream carrier |
ปลายทางคงที่ในทุกแถว และมีเพียงอัตลักษณ์ของต้นทางที่เปลี่ยน ข้อกำหนด UDP NAT แยกที่อยู่และพอร์ตภายในออกจากแมปปิงภายนอก ซึ่งเป็นความต่างระหว่างแถวที่สองและแถวที่สามพอดี เราเตอร์อาจรักษาพอร์ตต้นทางของผู้ใช้ไว้หรือเลือกพอร์ตอื่น การรักษาไว้ไม่ใช่สิ่งที่แอปพลิเคชันควรถือว่าเป็นจริง
อ่านปลายทั้งสามจากโฮสต์เอง
รายการด้านล่างมาจากเครื่องสามเครื่องที่ต่างกัน และเมื่อรวมกันแล้วแสดงบทสนทนาทั้งหมด รันรายการแรกบนเซิร์ฟเวอร์ รายการที่สองบนผู้ใช้ และรายการที่สามที่ใดก็ตามที่มีแมปปิงอยู่ บันทึกบรรทัดเดียวไม่เคยแสดงทั้งสาม
ss -lunp 'sport = :1194'
ss -unp | grep 1194
conntrack -L -p udp | grep 1194รายการแรกพิสูจน์ว่าเซิร์ฟเวอร์ผูกกับพอร์ตบริการและแสดงว่าโปรเซสใดเป็นเจ้าของ รายการที่สองแสดงซ็อกเก็ตภายในของผู้ใช้และปลายทางที่มันเรียกหา รายการที่สามแสดงแมปปิงที่เราเตอร์สร้างขึ้น และเป็นที่เดียวที่ต้นทางที่แปลแล้วปรากฏ อ่านตามลำดับนั้นแล้วตัวเลขทั้งสองจะไม่ดูขัดแย้งกันอีก
การเชื่อมต่อใหม่เปลี่ยนอะไร และไม่เปลี่ยนอะไร
เราเตอร์บางรุ่นรักษาพอร์ตต้นทางของผู้ใช้ไว้เมื่อว่าง ส่วนบางรุ่นจัดสรรพอร์ตใหม่ทุกครั้ง ทั้งสองพฤติกรรมเป็นเรื่องปกติ และแอปพลิเคชันที่ต้องการแบบแรกจะพังกับแบบที่สอง การเปลี่ยนแมปปิงหลังการเชื่อมต่อใหม่หรือการสลับเครือข่ายไม่ใช่ความผิดของเซิร์ฟเวอร์ ผู้ใช้เปิดซ็อกเก็ตใหม่ เราเตอร์จัดสรรเท่าที่มี และเซิร์ฟเวอร์เห็นต้นทางใหม่บนตัวรับฟังเดิม สิ่งที่จะเป็นความผิดคือการคาดว่าเซิร์ฟเวอร์จะรับทราฟฟิกที่ส่งถึงพอร์ตผู้ใช้ใดก็ได้
ผู้ใช้ OpenVPN ในชุมชนได้รับพฤติกรรมนี้ผ่าน nobind ซึ่งปล่อยให้ระบบปฏิบัติการเลือกพอร์ตภายใน พอร์ตระยะไกลยังคงมาจากโปรไฟล์ การผูกอย่างชัดเจนเป็นการเลือกโดยเจตนา ไม่ใช่ข้อกำหนดของโปรโตคอล เซิร์ฟเวอร์ยังคงเสนอปลายหนึ่งแห่ง ขณะที่ผู้ใช้เลือกอัตลักษณ์ภายในของตนเอง
ติดป้ายชั้นต่าง ๆ แยกกันในบันทึก
ภายในอุโมงค์มีบทสนทนาที่สองซึ่งมีพอร์ตของตัวเอง คำขอ HTTPS ที่อุโมงค์พามีปลายทาง TCP 443 ขณะที่การเชื่อมต่อเข้ารหัสชั้นนอกใช้ UDP 1194 ดังนั้นการเปลี่ยนพอร์ตต้นทางชั้นนอกไม่เปลี่ยนสิ่งใดในบริการชั้นใน
แม้ในชั้นนอก โปรโตคอลก็สำคัญ UDP 1194 และ TCP 1194 เป็นปลายที่ต่างกัน และตัวรับฟัง 'TCP' จะไม่ได้รับดาตาแกรม UDP เพราะหมายเลขตรงกันเพียงอย่างเดียว เมื่อจัดทำเอกสารการติดตั้ง ให้ติดป้ายตัวรับฟังของเซิร์ฟเวอร์ ซ็อกเก็ตของผู้ใช้ และต้นทางที่แปลแล้วเป็นสามสิ่งที่ต่างกัน และเพิ่มการขนส่งให้แต่ละอัน
จากนั้นให้แนวนโยบายตามบทบาท เซิร์ฟเวอร์เปิดการขนส่งที่ตั้งใจไว้บนตัวรับฟังของตนและยังคงตรวจสอบสิทธิ์คู่สนทนา ไฟร์วอลล์ของผู้ใช้ยอมรับคำตอบของการแลกเปลี่ยนขาออกของตนเองโดยไม่ประกาศบริการขาเข้า ตัวกรองแบบไม่มีสถานะต้องเขียนทิศทางย้อนกลับไว้อย่างชัดเจน และนี่คือเหตุผลเชิงปฏิบัติที่ความแตกต่างนี้สำคัญนอกเหนือจากแผนภาพที่เรียบร้อย