แชร์การเชื่อมต่อ VPN หนึ่งรายการให้ทุกอุปกรณ์บน LAN ของคุณ

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

ทำไมการชี้อุปกรณ์ไปที่โฮสต์จึงล้มเหลว

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

วินิจฉัยตามลำดับนั้นแทนการเปิดปิดการตั้งค่าแบบสุ่ม แต่ละชิ้นที่หายไปทำให้เกิดอาการที่แตกต่างกันเล็กน้อย

เปิดการส่งต่อและการแปลที่อยู่บนโฮสต์

การเปลี่ยนแปลงสองอย่างบนโฮสต์ที่เชื่อมต่อครอบคลุมสองชิ้นแรก: เปิดการส่งต่อ IPv4 และแปลทราฟฟิก LAN ไปยังอินเทอร์เฟซของอุโมงค์

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

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

ให้ LAN มีเส้นทางที่อยู่รอดหลังการรีบูต

อุปกรณ์อื่นต้องการเส้นทางไปยังคำนำหน้าระยะไกล และสองวิธีในการจัดหาเส้นทางนั้นแตกต่างกันในขอบเขตผลกระทบ

ip route add 10.8.0.0/24 via 192.168.1.20 dev eth0

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

ระวัง MTU ก่อนตำหนิอุโมงค์

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

ping -M do -s 1400 10.8.0.5

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

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