PiVPN แฮนด์เชคทำงาน แต่หน้าเว็บค้าง: ตรวจสอบ MASQUERADE

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

เริ่มจากสิ่งที่ไคลเอนต์เข้าถึงได้และเข้าถึงไม่ได้

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

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

ต่อไป ถามเซิร์ฟเวอร์ว่าจะใช้อินเทอร์เฟซใดเพื่อไปยังที่อยู่สาธารณะ ip route get 203.0.113.9 พิมพ์อุปกรณ์และแหล่งที่มาที่เลือกในบรรทัดแรก จดชื่ออุปกรณ์นั้นไว้ เพราะนั่นคือค่าที่กฎ NAT ต้องมี

อ่านกฎที่ตัดสินว่าแพ็กเก็ตจะออกไปหรือไม่

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

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

ip -br addr show tun0
ip route get 203.0.113.9
sudo iptables -t nat -S POSTROUTING

บน Raspberry Pi ที่เคยใช้ Ethernet และตอนนี้ใช้ Wi-Fi ชื่อที่ล้าสมัยมักเป็นเรื่องทั้งหมด อุปกรณ์ติดตั้งบันทึกว่ามีอุปกรณ์ใดตอนตั้งค่า และชุดกฎที่บันทึกไว้จะเล่นซ้ำในทุกการบูต ก่อนแก้อย่างอื่น ให้เปรียบเทียบอุปกรณ์จากค้นหาเส้นทางกับอุปกรณ์ในกฎ หากตรงกัน อินเทอร์เฟซไม่ใช่ปัญหาและคุณควรไปที่ตัวนับในส่วนสุดท้าย หากต่างกัน การแก้ไขคือแก้คำเดียวในไฟล์เก็บสถานะ

แก้ชุดกฎที่บันทึกไว้ ไม่ใช่แค่ชุดที่กำลังทำงาน

การแก้เฉพาะตารางที่ใช้งานอยู่จะอยู่ได้ถึงการรีบูตครั้งถัดไป ซึ่งนานพอที่จะทำให้คุณเชื่อว่าปัญหาแก้แล้ว กฎที่กลับมาที่การบูตอาศัยอยู่ในไฟล์ที่แพ็กเกจเก็บสถานะไฟร์วอลล์โหลดใหม่ บนอิมเมจ Pi ที่ใช้ Debian ไฟล์นั้นมักเป็น /etc/iptables/rules.v4.

สำรองก่อนแตะ จากนั้นแทนที่อินเทอร์เฟซขาออกในบรรทัด MASQUERADE ด้วยอุปกรณ์ที่คุณจดไว้ ตัวอย่างเช่น -o wlan0 แทน -o eth0 ปล่อยช่วงต้นทางไว้เหมือนเดิม เว้นแต่พูลไคลเอนต์ของคุณเปลี่ยนไป โหลดใหม่และยืนยันว่ากฎระบุอุปกรณ์ที่ถูกต้องแล้ว:

sudo cp /etc/iptables/rules.v4 /root/rules.v4.bak
sudo iptables-restore < /etc/iptables/rules.v4
sudo iptables -t nat -L POSTROUTING -v -n

การตั้งค่าที่อยู่ติดกันสองอย่างถูกลืมได้ง่าย sysctl net.ipv4.ip_forward ต้องรายงาน 1 และเราเตอร์ต้นน้ำต้องไม่กรองที่อยู่ต้นทางส่วนตัวเอง

พิสูจน์ว่ากฎทำงาน แล้วแยกแยะว่าอะไรยังช้าอยู่

ตัวนับเป็นหลักฐานเดียวที่ซื่อตรงว่ากฎจับคู่ได้ รันรายการแบบละเอียด เริ่มดาวน์โหลดบนไคลเอนต์ แล้วรันอีกครั้ง คอลัมน์แพ็กเก็ตและไบต์ข้างกฎของคุณควรเพิ่มขึ้น และกฎที่ยังเป็นศูนย์ก็ยังไม่ตรง หากตัวนับขยับแต่หน้าเว็บยังล้มเหลว ให้เปรียบเทียบช่วงต้นทางกับพูลจริงด้วย grep -n "^server " /etc/openvpn/server.conf หากขยับและหน้าเว็บโหลดได้แต่อัตราการส่งข้อมูลแย่ แปลว่าการแปลเสร็จแล้วและปัญหาที่เหลืออยู่ที่อื่น

เปรียบเทียบการถ่ายโอนสองครั้งจากไคลเอนต์เดียวกัน ครั้งหนึ่งไปยังโฮสต์ในเครือข่ายท้องถิ่น และอีกครั้งผ่านอุโมงค์ไปยังโฮสต์เดียวกัน ช้าในทั้งสองกรณีชี้ไปที่ลิงก์ต้นน้ำของ Pi หรือการเชื่อมต่อ Wi-Fi ไม่ใช่ VPN ช้าเฉพาะผ่านอุโมงค์ชี้ไปที่ MTU และการส่งซ้ำ ซึ่งตรวจสอบได้ด้วย ip -s link show tun0 ก่อนเปลี่ยนการตั้งค่าการเข้ารหัสใด ๆ

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