ควรเปิดพอร์ต VPN ใดบนไฟร์วอลล์: แยกตามโปรโตคอล
PPTP ต้องใช้ TCP 1723 และ GRE, L2TP/IPsec ต้องใช้ UDP 500 และ 4500 พร้อม ESP ส่วน SSTP, OpenVPN และ WireGuard ต้องใช้พอร์ตละหนึ่งพอร์ต นี่คือสิ่งที่ต้องเปิด
มีกฎสองข้อแยกกันที่ตัดสินว่าอุโมงค์ VPN จะผ่านไฟร์วอลล์ได้หรือไม่ คือพอร์ตที่ไคลเอนต์เรียกไป และโปรโตคอลที่บรรทุกเพย์โหลด ถ้าเปิดเพียงอย่างแรก อุโมงค์จะผ่านการยืนยันตัวตนได้ แต่หลังจากนั้นจะไม่มีข้อมูลวิ่งเลย ขั้นต่ำคือพอร์ต TCP หนึ่งพอร์ตกับ GRE สำหรับ PPTP พอร์ต UDP สองพอร์ตกับ ESP สำหรับ L2TP/IPsec และ IKEv2 และหนึ่งพอร์ตสำหรับ SSTP, OpenVPN และ WireGuard ทิศทาง การติดตามสถานะ และ NAT เป็นตัวกำหนดส่วนที่เหลือ
เริ่มจากพอร์ตที่ไคลเอนต์เรียกไป
แต่ละตระกูลมีจุดเข้าเดียวที่ไคลเอนต์ติดต่อก่อน และกฎอนุญาตของคุณต้องระบุชื่อจุดเข้านั้น PPTP เชื่อมต่อที่ TCP 1723 ส่วน L2TP/IPsec เริ่ม IKE บน UDP 500 และย้ายไป UDP 4500 เมื่อใช้การทะลุ NAT โดยเฟรม L2TP เองอยู่บน UDP 1701 ภายในอุโมงค์ SSTP ห่อเซสชันด้วย TLS บน TCP 443, IKEv2 เจรจาบน UDP 500 และ 4500, OpenVPN ใช้ UDP 1194 เป็นค่าเริ่มต้นแต่ถูกย้ายไป TCP 443 บ่อยครั้ง และ WireGuard รับฟังบน UDP 51820
| Family | Rule to add on the gateway | Typical mistake |
|---|---|---|
| WireGuard | UDP port from ListenPort, for the peer address | Assuming 51820 when the config says otherwise |
| OpenVPN | The configured UDP or TCP port, often 443 | Opening 1194 after the server moved |
| SSTP | TCP 443 limited to the gateway IP | Allowing 443 to any destination |
| IKEv2 | UDP 500 and UDP 4500, plus ESP | Allowing only 500 and losing NAT-T |
| L2TP/IPsec | UDP 500, 4500, ESP, and 1701 inside the tunnel | Exposing 1701 to the internet |
| PPTP | TCP 1723 and IP protocol 47 | Writing a rule for TCP 47 |
ให้ถือว่าตัวเลขเหล่านี้เป็นค่าเริ่มต้น ไม่ใช่คุณสมบัติตายตัว อินเทอร์เฟซ WireGuard ใช้พอร์ตรับฟังใดก็ได้ที่การกำหนดค่าประกาศไว้ และเซิร์ฟเวอร์ OpenVPN สามารถอยู่บนพอร์ตใดก็ได้ที่ผู้ดูแลเลือก อ่านการกำหนดค่าของเซิร์ฟเวอร์ก่อนเขียนกฎ เพราะไฟร์วอลล์ที่เปิดไว้สำหรับ 1194 ไม่มีประโยชน์กับเซิร์ฟเวอร์ที่ย้ายไป 443
คอลัมน์ที่สามคือจุดที่ตั๋วเปลี่ยนแปลงส่วนใหญ่ผิดพลาด กฎมีอยู่ แต่ชี้ไปยังปลายทางผิด ทิศทางผิด หรือการขนส่งผิด
GRE และ ESP เป็นหมายเลขโปรโตคอล ไม่ใช่พอร์ต
GRE และ ESP ไม่มีพอร์ตเลย ดังนั้นแบบฟอร์มไฟร์วอลล์ที่รับเฉพาะหมายเลขพอร์ตจึงบอกไม่ได้ GRE คือโปรโตคอล IP 47 และ ESP คือโปรโตคอล IP 50 ทั้งคู่จับคู่ผ่านฟิลด์โปรโตคอลในส่วนหัว IP กฎที่เขียนเป็นพอร์ต TCP 47 จะไม่ตรงกับอะไรเลย และนี่คือวิธีที่นโยบาย PPTP ดูถูกต้องแต่ยังทิ้งทุกแพ็กเก็ตหลังการจับมือ
เราเตอร์สำหรับผู้ใช้ทั่วไปซ่อนเรื่องนี้ไว้หลังช่องทำเครื่องหมายส่งผ่าน ซึ่งติดตั้งกฎโปรโตคอลและสำหรับ GRE ก็ติดตั้งตัวช่วย NAT ที่จำเป็นในการแมปโฟลว์ บนไฟร์วอลล์จริงคุณเพิ่มโปรโตคอลเอง อนุญาตโปรโตคอล IP 47 ไปยังเซิร์ฟเวอร์ PPTP และอนุญาตโปรโตคอล IP 50 ไปยังเกตเวย์ IPsec ที่ใดที่แพลตฟอร์มไม่มีฟิลด์โปรโตคอล การห่อหุ้มคือทางออก นี่คือเหตุผลที่ IKEv2 ถอยกลับไป UDP 4500 ได้ และเป็นเหตุผลที่ OpenVPN กับ WireGuard ไม่เคยเจอปัญหานี้
ตรวจสอบว่ากฎตรงกับอะไรจริง ๆ ก่อนโทษไคลเอนต์ ตัวนับแพ็กเก็ตที่ค้างอยู่ที่ศูนย์บนเกตเวย์บอกว่ากฎไม่เคยถูกเรียกใช้ และการติดตั้งใหม่ฝั่งไคลเอนต์กี่ครั้งก็ไม่เปลี่ยน
ทิศทาง สถานะ และ NAT เปลี่ยนคำตอบ
ไคลเอนต์ที่เรียกออกไปกับเกตเวย์ที่รับฟังเข้ามาเป็นความต้องการคนละแบบ และรายการพอร์ตเดียวกันอาจถูกในทิศทางหนึ่งและผิดในอีกทิศทาง ไฟร์วอลล์ที่ติดตามสถานะจะติดตามโฟลว์ UDP บน 500 และ 4500 และปล่อยคำตอบกลับได้โดยไม่ต้องมีกฎที่สอง ESP และ GRE ไม่บรรทุกพอร์ต อุปกรณ์ NAT จึงไม่มีอะไรให้ยึด และต้องมีตัวช่วยหรือการห่อหุ้มเพื่อติดตามเซสชัน
การทะลุ NAT คือส่วนที่มักถูกละเลย IKEv2 เริ่มบน UDP 500 ตรวจพบอุปกรณ์ NAT แล้วดำเนินต่อบน UDP 4500 นโยบายที่อนุญาตเพียง 500 จึงให้อุโมงค์ที่สร้างเสร็จแล้วเงียบไป L2TP/IPsec ก็เคลื่อนแบบเดียวกัน หากการดักจับของคุณเห็นการแลกเปลี่ยนแรกแต่ไม่เห็นทราฟฟิกต่อเนื่อง ให้มองหากฎที่หยุดที่ 500
บันทึกทิศทางไว้กับทุกกฎ «อนุญาต UDP 4500» ไม่มีความหมายจนกว่าคุณจะบอกว่าจากไหนไปไหน และกฎที่ถูกสำหรับไคลเอนต์ที่เคลื่อนที่มักผิดสำหรับคู่ site-to-site
ตรวจสอบทุกเส้นทางด้วยการดักจับ
รันการดักจับบนเกตเวย์ ไม่ใช่บนไคลเอนต์ เพราะไคลเอนต์บันทึกเฉพาะสิ่งที่มาถึง ตัวกรองเหล่านี้ครอบคลุมตระกูลข้างต้นและแสดงว่าขั้นตอนใดหายไป
sudo tcpdump -ni any tcp port 1723
sudo tcpdump -ni any udp port 500 or udp port 4500
sudo tcpdump -ni any proto gre
sudo tcpdump -ni any proto 50อ่านผลลัพธ์เป็นลำดับ เมื่อการเจรจาปรากฏแต่โปรโตคอลเพย์โหลดไม่ปรากฏ การทิ้งเกิดขึ้นที่ใดที่หนึ่งระหว่างไคลเอนต์กับเกตเวย์ เมื่อทั้งคู่ปรากฏแต่หน้าเว็บยังล้มเหลว ไฟร์วอลล์ไม่ใช่ผู้ต้องสงสัยอีกต่อไป ให้ดูการกำหนดเส้นทาง DNS หรือพูลแอดเดรสที่มอบให้ไคลเอนต์
บนเครื่องที่ไม่มี tcpdump หลักฐานเดียวกันมาจากตัวนับอินเทอร์เฟซและกฎ ไบต์ที่เข้ามาแต่ไม่ออกบนอินเทอร์เฟซอุโมงค์ชี้ไปที่เส้นทางขากลับ ไม่ใช่กฎอนุญาตเริ่มต้น
ทิ้งชุดกฎที่คุณปกป้องได้
SSTP บน TCP 443 แยกจาก HTTPS ปกติไม่ได้สำหรับตัวกรองที่อิงพอร์ตใด ๆ และนั่นคือจุดประสงค์เมื่อเครือข่ายอนุญาตเฉพาะทราฟฟิกเว็บ ดังนั้นกฎสำหรับ 443 ควรระบุเกตเวย์เป็นปลายทางแทนอินเทอร์เน็ตทั้งหมด ลบกฎชั่วคราวแบบใดก็ได้ไปยังใดก็ได้ทันทีที่อุโมงค์ทำงาน บันทึกว่ากฎใดตรง มีหมายเลขโปรโตคอลตรงไหน และทิศทาง เพื่อให้คนถัดไปเริ่มจากหลักฐาน
เกตเวย์คลาวด์แบบจุดไปไซต์ทำให้เห็นทางเลือกชัดเจน โปรไฟล์ที่ดาวน์โหลดใช้ SSTP บน 443 หรือ IKEv2 บน 500 และ 4500 และคุณควรเปิดเฉพาะสิ่งที่โปรไฟล์เลือกจริง ๆ PPTP ไม่คุ้มกับการยกเว้น GRE ในเครือข่ายสมัยใหม่ เพราะผู้ให้บริการมือถือมักทิ้งโปรโตคอล 47 โดยไม่สนใจไฟร์วอลล์ของคุณ ก่อนปิดตั๋ว ให้ยืนยันว่ากฎตรงกับพอร์ตในการกำหนดค่าเซิร์ฟเวอร์ ฟิลด์โปรโตคอลถูกตั้งไว้ในที่ที่ตระกูลนั้นต้องการ และปลายทางคือเกตเวย์ไม่ใช่แอดเดรสใด ๆ