อุโมงค์ VPN ไม่เชื่อมต่อเลย: แพ็กเก็ตหยุดอยู่ที่ใดจริง ๆ

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

พิสูจน์ว่าทราฟฟิกหยุดที่ใด

จับแพ็กเก็ตพร้อมกันที่อินเทอร์เฟซขาออกของไคลเอนต์และที่เซิร์ฟเวอร์ เปรียบเทียบสิ่งที่ออกไปกับสิ่งที่มาถึง และบันทึกว่าความแตกต่างปรากฏในทิศทางใด

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

PPTP ตายโดยไม่มีโปรโตคอล 47

PPTP พาการควบคุมบน TCP 1723 และข้อมูลไว้ใน GRE ซึ่งเป็นโปรโตคอล IP 47 ไม่ใช่หมายเลขพอร์ต การส่งต่อเพียง 1723 ให้ผลลัพธ์แบบคลาสสิก: การเชื่อมต่อผ่านการรับรองความถูกต้องแล้วเงียบไป เพราะไม่มีกฎสำหรับโปรโตคอลที่พาเพย์โหลด ไคลเอนต์แยกสิ่งนี้จากรหัสผ่านที่ถูกปฏิเสธไม่ได้ การจับแพ็กเก็ตจึงต้องมาก่อนการแก้ไขการกำหนดค่า

พาสทรูทำงานในทิศทางตรงข้ามกับการส่งต่อขาเข้า และเฟิร์มแวร์มักใช้ป้ายเดียวกันกับทั้งสองบ่อยพอที่จะทำให้ทุกคนสับสน บนไคลเอนต์ลินุกซ์ไฟร์วอลล์ภายในเครื่องอาจทิ้ง GRE นานก่อนที่เราเตอร์จะเกี่ยวข้อง โปรโตคอล 47 จึงต้องมีกฎของตัวเองและต้องโหลดตัวช่วย conntrack ufw ของอูบุนตูเก็บกฎเหล่านี้ไว้ในไฟล์ before เพราะกฎ allow ทั่วไปไม่สามารถแสดงหมายเลขโปรโตคอลได้ หลังจากนั้นให้โหลดไฟร์วอลล์ใหม่แทนการรีบูตเครื่อง

# /etc/ufw/before.rules, inside *filter
-A ufw-before-input -p gre -j ACCEPT
sudo ufw allow 1723/tcp
sudo modprobe nf_conntrack_pptp
sudo conntrack -L | grep gre

L2TP และ IPsec หลัง NAT สองชั้น

L2TP ภายใน IPsec ต้องใช้ UDP 500 สำหรับการแลกกุญแจ UDP 4500 เมื่อตรวจพบ NAT และ ESP เป็นโปรโตคอล 50 แต่ละตัวถูกกรองแยกกัน กฎที่อนุญาตตัวหนึ่งจึงไม่ได้พิสูจน์อะไรเกี่ยวกับอีกสองตัว เราเตอร์สองตัวต่อกันแปลทุกแพ็กเก็ตสองครั้ง และปลายทางทั้งสองไม่ตรงกันอีกต่อไปว่าตกลงอะไรไว้

บริดจ์โมเด็มภายนอก หรือปิด NAT บนเราเตอร์ภายใน เพื่อให้ที่อยู่สาธารณะไปถึงอุปกรณ์ที่ยุติอุโมงค์ ในกรณีที่ทำไม่ได้ทั้งสองอย่าง ต้องเริ่มอุโมงค์จากภายในขอบเขต NAT สองชั้น ไม่ใช่ยุติที่นั่น

เครือข่ายผู้ให้บริการและการแชร์ที่อยู่

ที่อยู่ WAN ที่อยู่ใน 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 หรือ 100.64.0.0/10 หมายความว่าเราเตอร์ไม่มีที่อยู่สาธารณะ และการส่งต่อขาเข้าจากอินเทอร์เน็ตไม่สามารถไปถึงได้ NAT ระดับผู้ให้บริการยังกรองโปรโตคอลที่ไม่คาดคิด และ GRE มักตกเป็นเหยื่อบนลิงก์มือถือ เปรียบเทียบที่อยู่ WAN บนตัวเราเตอร์เอง ไม่ใช่ที่อยู่ที่เว็บไซต์ค้นหาแจ้งสำหรับไคลเอนต์ที่อยู่ข้างหลัง

การรันเราเตอร์เดียวกันบนสายเคเบิลแยกข้อสรุปเกี่ยวกับผู้ให้บริการออกจากข้อผิดพลาดในการกำหนดค่าในการทดสอบครั้งเดียว เมื่อผู้ให้บริการปฏิเสธโปรโตคอล ทางเลือกที่เหลือคือการขนส่งอื่นบน 443 หรืออุโมงค์ที่เริ่มจากภายใน

อ่านรายการผู้ฟังก่อนปิดพอร์ต

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

ss -lntup
systemctl list-units --type=service --state=running | grep -i vpn
nc -vz 203.0.113.10 1723
nc -vzu 203.0.113.10 4500

ค่าเริ่มต้นของ SoftEther เป็นตัวอย่างที่ดี: TCP 443, 992 และ 5555 โดยฟีเจอร์ L2TP/IPsec และอุโมงค์ DNS เพิ่มซ็อกเก็ตของตัวเอง การปิดฟีเจอร์เหล่านั้นจะนำผู้ฟังออกไปแทนการซ่อน และการทดสอบจากโฮสต์ภายนอกบอกว่าผู้ให้บริการยอมให้พอร์ตผ่านหรือไม่ ผู้ฟังที่ตอบในเครื่องอาจยังถูกปิดอยู่เหนือขึ้นไป จึงเปรียบเทียบที่อยู่ WAN ของเราเตอร์เองกับสิ่งที่บริการภายนอกรายงาน