ไคลเอนต์ VPN เชื่อมต่อได้แต่ไม่มีอินเทอร์เน็ต: สามส่วนที่ขาดหาย

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

ทำไมอุโมงค์ที่ใช้งานได้จึงยังไม่มีทางออก

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

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

ดังนั้นจงทดสอบสามชั้นแทนที่จะทดสอบไคลเอนต์ และเปลี่ยนทีละอย่างเพื่อให้ผลลัพธ์มีความหมาย

การส่งต่อคือสวิตช์ของเคอร์เนลที่ต้องทำให้ถาวร

ตรวจสอบค่าปัจจุบันก่อนเปลี่ยนแปลง จากนั้นตั้งค่าและยืนยันว่าการเปลี่ยนแปลงมีผล

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

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

ทำให้ถาวรในไฟล์ใต้ /etc/sysctl.d/ แล้วนำไฟล์นั้นไปใช้แทนการรีบูตเพื่อดูผล ใน FreeBSD ค่าที่เทียบเท่าคือ net.inet.ip.forwarding และเพื่อความถาวรให้ใช้ gateway_enable=YES ใน rc.conf อุปกรณ์ที่รายงานว่าปิดการส่งต่ออธิบายรายงานทั้งชั้นที่ว่า «แพ็กเก็ตมาถึงแต่ไม่มีอะไรกลับไป» ตรวจสอบการตั้งค่าหลังการอัปเกรดทุกครั้งด้วย เพราะเคอร์เนลที่สร้างใหม่หรืออิมเมจอุปกรณ์ที่เปลี่ยนอาจรีเซ็ตค่านั้นโดยไม่บอกใคร

เลือก masquerade หรือที่อยู่แปลค่าเดียวที่คงที่

เมื่อที่อยู่ภายนอกเป็นแบบไดนามิก masquerading เป็นรูปแบบที่ถูกต้องและง่ายที่สุด ตั้งชื่อซับเน็ตของอุโมงค์เป็นต้นทางและอินเทอร์เฟซภายนอกเป็นทางออก

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE

เมื่อที่อยู่สาธารณะเป็นแบบคงที่ การแปลต้นทางไปยังที่อยู่นั้นโดยตรงคาดเดาได้ง่ายกว่าและตรวจสอบได้ง่ายกว่า

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

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

ตารางฟิลเตอร์คือประตูที่สาม

การส่งต่อและการแปลอาจถูกต้องทั้งคู่ แต่แพ็กเก็ตยังตายในตารางฟิลเตอร์ ufw เป็นผู้กระทำผิดบ่อย: นโยบายการส่งต่อของมันมาพร้อมค่า DROP และการตั้งค่าที่เหลืออาจดูถูกต้องสมบูรณ์ในขณะที่การตั้งค่าเดียวนั้นฆ่าทราฟฟิก การยกมันขึ้นเป็นการตัดสินใจด้านความปลอดภัยโดยเจตนา ไม่ใช่ช่องทำเครื่องหมาย

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

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

จะดูตรงไหนเมื่อหน้าเว็บไม่โหลดเลย

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

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

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

บนเซิร์ฟเวอร์ ให้เฝ้าดูอินเทอร์เฟซภายนอกในขณะที่ไคลเอนต์โหลดหน้า ทราฟฟิกที่ออกไปพร้อมที่อยู่ต้นทางส่วนตัวหมายความว่าขาดการแปล และการไม่มีคำตอบเลยหมายความว่าเส้นทางส่งต่อหรือเส้นทางกลับต้นทางกำลังทิ้งมัน

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