ข้อกำหนดพอร์ต VPN: สามบรรทัดที่ต้องเขียนก่อนเปรียบเทียบ
ระบุว่าคุณมีคำถามเรื่องพอร์ตใดจริง ๆ ปลายทางขาออก การเผยแพร่ขาเข้า หรือการขนส่งของอุโมงค์เอง จากนั้นถามผู้ให้บริการเพียงเรื่องนั้น
รายการพอร์ตของบริการ VPN ถูกคัดลอกระหว่างหน้าเปรียบเทียบโดยไม่มีรายละเอียดที่กำหนดว่ามันสำคัญหรือไม่ นั่นคือ ใครเป็นผู้เริ่มการเชื่อมต่อ กฎที่อนุญาต TCP 443 ขาออกไม่ได้บอกอะไรเลยว่าโฮสต์อื่นจะเข้าถึงตัวรับฟังบนเครื่องของคุณได้หรือไม่ เขียนข้อกำหนดแยกกันสามข้อก่อนจะเปรียบเทียบแผนใด ๆ และทำเครื่องหมายว่าข้อใดที่งานของคุณต้องการจริง ๆ เมื่อมีแผ่นงานนั้นแล้ว การเปรียบเทียบส่วนใหญ่จะเหลือเพียงคำถามสั้น ๆ ข้อเดียว
แยกข้อกำหนดก่อนอ่านรายการพอร์ตใด ๆ
สามบรรทัดครอบคลุมเกือบทุกกรณี การไปถึงปลายทางที่อยู่นอกอุโมงค์ การเผยแพร่บางสิ่งเพื่อให้ผู้อื่นเชื่อมต่อเข้ามาได้ และการบรรทุกตัวอุโมงค์เอง แต่ละบรรทัดล้มเหลวด้วยเหตุผลต่างกัน และนโยบายของผู้ให้บริการที่ตอบสนองบรรทัดหนึ่งอาจปล่อยอีกสองบรรทัดไว้ไม่แตะต้อง การจัดงานของคุณให้อยู่บรรทัดที่ถูกต้องใช้เวลาห้านาทีและประหยัดการโต้เถียงในภายหลัง
| Line | Who starts it | What can block it | Question for the provider |
|---|---|---|---|
| Outbound destination | Your application | Egress filter on the exit node | Is this protocol and port allowed to that destination? |
| Inbound publishing | A remote peer | No mapping, no public address, short lifetime | Which protocol, which external port, and how long does the mapping last? |
| Tunnel transport | Your client to the gateway | The access network drops that protocol | Does the client offer a fallback the local network permits? |
ถ้อยแถลงทางการตลาดทำให้สามบรรทัดคลุมเครือโดยเจตนา การอนุญาต P2P อธิบายนโยบายปลายทาง ที่อยู่เฉพาะอธิบายที่อยู่ และการอ้างว่าไม่มีข้อจำกัดเรื่องพอร์ตมักหมายความว่าแผนไม่ได้ระบุไว้ ไม่มีวลีใดในนั้นตอบวลีอื่น
เลือกกระแสหนึ่งอย่างเป็นรูปธรรมแล้วเขียนเป็นประโยค ผู้เริ่มต้น การขนส่ง พอร์ต ตระกูลที่อยู่ ทิศทาง ไคลเอนต์สำรองข้อมูลกลางคืนที่อัปโหลดไปยังโฮสต์ระยะไกลเป็นขาออกเท่านั้น เซิร์ฟเวอร์เกมบนโต๊ะของคุณที่เพื่อนเข้าร่วมเป็นขาเข้า การรันทั้งสองผ่านอุโมงค์เดียวหมายความว่าแผ่นงานต้องมีทั้งสองบรรทัด ไม่ใช่การประนีประนอมระหว่างกัน
การเข้าถึงขาออกล้มเหลวที่นโยบายปลายทาง ไม่ใช่อุโมงค์
ทราฟฟิกขาออกผ่านเกตเวย์ที่แปลจะสร้างสถานะ แพ็กเก็ตแรกจากที่อยู่และพอร์ตภายในจะสร้างรายการแปล และคำตอบจะตรงกับรายการนั้น ซึ่งเป็นพฤติกรรมการแมปที่อธิบายไว้ใน RFC 3022 กลไกนี้คือเหตุผลที่แท็บเบราว์เซอร์มักทำงานได้โดยไม่ต้องมีคำขอพอร์ตใด ๆ
สองสิ่งยังคงทำให้มันพัง โหนดขาออกอาจกรองปลายทางหรือหมายเลขพอร์ตที่เห็นว่าใช้ในทางที่ผิด และแอปพลิเคชันอาจกำลังรับฟังบนพอร์ตที่นโยบายขาออกไม่เคยคาดคิด ถามถึงคู่ปลายทางไม่ใช่กฎขาเข้า และคาดหวังคำตอบที่ต่างกันสำหรับ TCP และ UDP
วัดก่อนโต้แย้ง รันคำสั่งเหล่านี้บนเครื่องที่จะอยู่หลังอุโมงค์ ครั้งหนึ่งเมื่ออุโมงค์ปิด และอีกครั้งเมื่อเปิด:
ss -lntup | sort
nc -vz -w 3 203.0.113.10 443
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://example.com
คำสั่งเดิม ปลายทางเดิม สองสถานะของอุโมงค์ ให้ผู้ปฏิบัติงาน การเปรียบเทียบก่อนและหลังที่เขาลงมือได้ แทนที่ที่อยู่เอกสารด้วยโฮสต์ที่คุณต้องการจริง ๆ สิ่งสำคัญคือการเปรียบเทียบนั้นทำซ้ำ ไม่ใช่ว่าตัวเลขใดดูน่าประทับใจ
การเผยแพร่ขาเข้าต้องมีการแมป ที่อยู่ และอายุการใช้งาน
ไม่มีสิ่งใดจากภายนอกเริ่มการเชื่อมต่อกับตัวรับฟังของคุณได้ เว้นแต่มีบางสิ่งฝั่งสาธารณะรู้ว่าจะส่งไปที่ใด การจองพอร์ตแบบคงที่ที่ผู้ปฏิบัติงานถือไว้ การแมปที่ไคลเอนต์ขอผ่าน UPnP, NAT-PMP หรือ PCP และที่อยู่สาธารณะที่กำหนดเส้นทางแล้ว คือผลิตภัณฑ์สามแบบที่แตกต่างกันพร้อมขีดจำกัดสามอย่าง
ถามห้าคำถามกับสิ่งใดสิ่งหนึ่งเหล่านี้ ใช้โปรโตคอลใด พอร์ตภายนอกใด พอร์ตภายนอกต่างจากพอร์ตภายในได้หรือไม่ ครอบคลุมตระกูลที่อยู่ใด และการแมปอยู่ได้นานเท่าใดหลังการเชื่อมต่อใหม่ การจองที่ผูกกับเซสชันที่ใช้งานอยู่จะหายไปเมื่อเซสชันนั้นสิ้นสุด ไม่ว่าแผนจะเขียนว่าอย่างไร
ยืนยันครึ่งฝั่งท้องถิ่นก่อน เพราะตัวรับฟังที่ตายแล้วและเส้นทางขาเข้าที่ถูกปิดกั้นดูเหมือนกันจากภายนอก:
ss -lntup | grep -E ':(8080|51820)\b'
python3 -m http.server 8080 --bind 0.0.0.0
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080
เมื่อคำขอภายในคืนค่า 200 และคำขอจากเครือข่ายที่คุณไม่ได้ควบคุมยังคงหมดเวลา ช่องว่างอยู่ฝั่งสาธารณะ นั่นคือจังหวะที่ควรบอกผู้ปฏิบัติงานถึงโปรโตคอลและพอร์ตภายนอก แทนที่จะอธิบายแอปด้วยชื่อ
การขนส่งของอุโมงค์เองเป็นคำถามแยก
พอร์ตของตัวพาเป็นส่วนที่เล็กที่สุดของปัญหาและหาดูได้ง่ายที่สุด ค่าเริ่มต้นแตกต่างกันตามโปรโตคอล และสิ่งที่ไคลเอนต์เจรจาได้สำคัญกว่าคำอธิบายแผนใด ๆ
| Client | Outer transport | Default port | When it helps |
|---|---|---|---|
| OpenVPN | UDP | 1194 | Default mode; needs outbound UDP to pass |
| OpenVPN | TCP | 443 | UDP is dropped and TCP 443 is not |
| WireGuard | UDP | 51820 | Short handshake; there is no TCP mode |
| IKEv2/IPsec | UDP | 500 and 4500 | Mobile clients; 4500 carries NAT traversal |
เครือข่ายที่ทิ้ง UDP ขาออกจะยอมรับอุโมงค์ TCP 443 และปฏิเสธอุโมงค์ UDP ดังนั้นโหมดสำรองจึงอยู่ในแผ่นข้อกำหนด การเปลี่ยนตัวพาไม่ย้ายพอร์ตแอปพลิเคชันภายในอุโมงค์ และไม่ขยายนโยบายปลายทาง สิ่งเหล่านั้นยังอยู่ในบรรทัดของตนเอง
การแบ่งส่วนควรค่าแก่การทดสอบหนึ่งครั้งในขณะที่คุณอยู่ที่นั่น เพราะอุโมงค์ที่เชื่อมต่อแล้วติดขัดในการถ่ายโอนขนาดใหญ่มักมี MTU ผิด ไม่ใช่พอร์ตที่ปิด
ping -M do -s 1400 203.0.113.10 ping -M do -s 1372 203.0.113.10
บน Windows การทดสอบเดียวกันคือ ping -f -l 1400 203.0.113.10 ตั้งค่า MTU ของอุโมงค์ให้ต่ำกว่าขนาดใหญ่ที่สุดที่ผ่านได้ แล้วทดสอบการถ่ายโอนที่ล้มเหลวอีกครั้ง
ตรวจสอบสามบรรทัดก่อนจ่ายเงินค่าแผน
วางสามบรรทัดบนหน้าเดียวและเติมแต่ละช่องด้วยผลลัพธ์ที่วัดได้แทนคำสัญญา คำสั่งเหล่านี้สร้างครึ่งฝั่งท้องถิ่นของหน้านั้นในเวลาประมาณหนึ่งนาที:
ss -lntup | sort
nc -vz -w 3 203.0.113.10 443
python3 -m http.server 8080 --bind 0.0.0.0
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080
ping -M do -s 1400 203.0.113.10
อ่านเอาต์พุตเป็นรายการตรวจสอบ ขาออกทำงานเมื่อปลายทางตอบกลับขณะอุโมงค์เปิด ขาเข้าทำงานเฉพาะเมื่อโฮสต์ภายนอกเครือข่ายของคุณเข้าถึงตัวรับฟังบนพอร์ตภายนอก ตัวพาทำงานเมื่อการจับมือเสร็จสิ้นบนโปรโตคอลที่เครือข่ายการเข้าถึงของคุณอนุญาต
นิสัยสองอย่างทำให้แผ่นงานซื่อตรง บันทึกวันที่และเวอร์ชันไคลเอนต์ข้างผลลัพธ์แต่ละรายการ เพราะทั้งนโยบายของผู้ให้บริการและค่าเริ่มต้นของไคลเอนต์ต่างเคลื่อนไหว จากนั้นขอการแมปที่แคบที่สุดซึ่งให้บริการกระแสนั้น เพราะคำขอเปิดทุกอย่างมักได้การปฏิเสธหรือการขายเพิ่มแทนคำตอบทางเทคนิค