VPN กับ LAN ที่บ้านใช้ซับเน็ตเดียวกัน: ตามเส้นทางก่อน
อะแดปเตอร์ทั้งสองอ้าง 192.168.1.0/24 และมีเพียงเส้นทางเดียวที่ชนะ ตามรายการอะแดปเตอร์ เส้นทางที่ชนะ และทางกลับ ก่อนที่จะเปลี่ยนเลขหรือโทษ DNS
คุณเชื่อมต่อ VPN ของออฟฟิศ ไอคอนในถาดเป็นสีเขียว อินทราเน็ตโหลดขึ้น และเครื่องพิมพ์ที่อยู่ห่างสองเมตรก็หยุดตอบสนอง โฟลเดอร์แชร์ที่ใช้ได้ตอนเช้าก็หมดเวลาบนเครื่องเดียวกัน และไม่มีบันทึกใดเอ่ยถึงเครื่องพิมพ์ ปฏิกิริยาแรกคือ DNS เพราะชื่อที่แก้ไม่ออกดูเหมือนชื่อที่ไม่มีอยู่ แต่ปัญหาอยู่ที่ที่อยู่: อะแดปเตอร์สองตัวอ้าง 192.168.1.0/24 แล้ว และมีเพียงเส้นทางเดียวที่ชนะคำนำหน้านี้ได้ ตามลำดับนี้แล้วคุณจะเห็นว่าอะแดปเตอร์ตัวไหนเอาที่อยู่ไปก่อนที่คุณจะเปลี่ยนอะไร
เริ่มจากอาการ ไม่ใช่จากอุโมงค์
เบาะแสคือขอบเขต ถ้าอินทราเน็ตใช้ได้และอุปกรณ์ในบ้านทุกตัวล้ม แสดงว่าอุโมงค์ปกติและเส้นทางภายในมีปัญหา ถ้าอุปกรณ์ในบ้านใช้ได้แต่อินทราเน็ตล้ม ก็กลับกัน ถ้าทุกอย่างใช้ได้ยกเว้นโฮสต์เดียว คุณกำลังดูที่อยู่เดียวที่มีอยู่ทั้งสองฝั่ง
จดที่อยู่ในบ้านหนึ่งรายการและที่อยู่ระยะไกลหนึ่งรายการก่อนแตะการตั้งค่า “เครื่องพิมพ์” ทดสอบไม่ได้ แต่ 192.168.1.40 ทดสอบได้ ขั้นตอนเดียวนี้ป้องกันชั่วโมงที่สูญเสียบ่อยที่สุดในปัญหานี้ คือการเขียนการตั้งค่า DNS ใหม่เพื่อตัดสินใจเรื่องเส้นทาง
ขั้นที่ 1: ดูอะแดปเตอร์ทั้งสองที่อ้างคำนำหน้า
เปิดการเชื่อมต่อเครือข่าย (ncpa.cpl) แล้วอ่านอะแดปเตอร์ทั้งสองตัวเทียบกัน อะแดปเตอร์ Ethernet แสดง 192.168.1.50/24 พร้อมเกตเวย์ 192.168.1.1 อะแดปเตอร์ VPN แสดง 192.168.1.201/24 ที่เซิร์ฟเวอร์ส่งมา ทั้งสองถูกต้อง ทั้งสองเชื่อว่าคำนำหน้าเป็น on-link และสแตกจะเก็บเส้นทางเดียวไว้สำหรับมัน
Get-NetIPAddress -AddressFamily IPv4 แสดงรายการที่อยู่ และ Get-NetIPInterface | Sort-Object InterfaceMetric แสดงลำดับที่สแตกจะใช้ คอลัมน์เมตริกนั้นคือการตัดสินใจที่คุณกำลังจะอ่าน ดังนั้นจดตัวเลขไว้แทนที่จะพยายามจำ
หักล้างทฤษฎี DNS แบบประหยัด: Resolve-DnsName printer.office.lan คืนที่อยู่เดียวกับเมื่อวาน ชื่อแก้ได้แล้ว จากนั้นแพ็กเก็ตออกทางอะแดปเตอร์ผิดตัว สองนาทีตรงนี้ประหยัดบ่ายทั้งบ่ายในการตั้งค่าตัวแก้ชื่อ
ขั้นที่ 2: อ่านเส้นทางที่ชนะจริง
Find-NetRoute -RemoteIPAddress 192.168.1.40 พิมพ์อินเทอร์เฟซ ฮอปถัดไป และแหล่งที่มาที่สแตกจะใช้สำหรับที่อยู่นั้น ถือว่าผลลัพธ์นั้นคือคำตอบ ไม่ใช่เบาะแส route print -4 ให้ตารางทั้งหมดเมื่อคุณอยากเห็นว่ารายการไหนแพ้และแพ้ไปเท่าไร
ความจำเพาะชนะเจตนา 192.168.0.0/25 ที่ถูกส่งมาชนะ 192.168.0.0/24 ในเครื่อง เพราะคำนำหน้ายาวกว่า ดังนั้น 192.168.0.0 ถึง 192.168.0.127 ออกทางอุโมงค์ ขณะที่ครึ่งบนยังอยู่ภายในเครื่อง การที่ครึ่งหนึ่งของ LAN หายไปโดยไม่มีข้อความแสดงข้อผิดพลาดคือพฤติกรรมที่ถูกต้องของตารางนั้น
tracert -d 192.168.1.40 ยืนยันจากนอกตาราง: ถ้าฮอปแรกเป็นที่อยู่ของอุโมงค์แทนที่จะเป็นเราเตอร์ของคุณ เส้นทางก็คือเรื่องทั้งหมด บน Linux คำถามเดียวกันคือ ip route get 192.168.1.40 ซึ่งพิมพ์ที่อยู่ต้นทางและอุปกรณ์ในบรรทัดเดียว เมื่อคำตอบระบุ tun0 ให้หยุดดูเบราว์เซอร์
ขั้นที่ 3: ตรวจทางกลับก่อนโทษไคลเอนต์
เส้นทางขาไปที่ถูกต้องยังล้มเหลวถ้าฝั่งไกลตอบไม่ได้ เมื่อเข้าถึง LAN ของไคลเอนต์ผ่านอุโมงค์ เกตเวย์ของ LAN นั้นต้องรู้ว่าพูลของอุโมงค์อยู่ที่ไหน: ip route add 10.8.0.0/24 via 192.168.1.12 บนเราเตอร์นั้น และ push “route 192.168.1.0 255.255.255.0” จากเซิร์ฟเวอร์เพื่อให้ไคลเอนต์รู้ทางกลับ
หากไม่มีรายการแรก คำตอบจะออกจากปลายทางไปยังเกตเวย์เริ่มต้นของมัน ซึ่งส่งที่อยู่ส่วนตัวให้ผู้ให้บริการแล้วทิ้งไป อาการเป็นทางเดียวและอ่านผิดได้ง่าย: คำขอปรากฏบน tun0 แต่คำตอบไม่เคยปรากฏ
กฎ masquerade บนโฮสต์ VPN ขจัดการต้องมีเส้นทางสถิตนั้น: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE มันยังซ่อนที่อยู่ต้นทางจริง ซึ่งทำให้ทุกคำถามบันทึกภายหลังยากขึ้น โฮสต์ปลายทางที่มีเกตเวย์เริ่มต้นผิดก็ให้ความเงียบแบบเดียวกัน โดยมี ICMP รีไดเรกต์เป็นกรณีที่ดีที่สุดและหลุมดำเป็นกรณีปกติ จึงต้องดักจับทั้งสองฝั่ง
ขั้นที่ 4: เลือกการซ่อมที่คุณอยู่ด้วยได้
มีการซ่อมห้าแบบสำหรับเรื่องนี้ และใช้แทนกันไม่ได้ เลือกตามสิ่งที่ต้องเข้าถึงได้พร้อมกัน ไม่ใช่ตามคำสั่งที่สั้นที่สุด
| Repair | What it fixes | What it costs |
|---|---|---|
| Flip interface metrics | Alternating access: office now, home later, never both | Get-NetAdapter -Name "Ethernet 2" | Set-NetIPInterface -InterfaceMetric 21; set the VPN adapter back to 5000. A client that rewrites metrics on connect defeats it |
| Renumber one side | Every host reachable in both directions | DHCP reservations, printer queues, firewall rules and hard-coded addresses all move |
| Narrow the advertised prefix | Remote hosts really live in the upper half | Breaks the day someone adds a host below the cut |
| Translate with client-nat | Both address plans stay untouched | Stateless per-client mapping, unreadable logs, anything embedding addresses breaks |
| Publish one service with DNAT | One service on the VPN host reachable from the LAN | Both address plans stay; source addresses and reverse lookups stop being meaningful |
เมตริกเป็นตัวเลือกที่ถูกและเป็นตัวแรกที่คนเอื้อมถึง การเปลี่ยนแปลงมีผลกับอินเทอร์เฟซ จึงใช้ได้ขณะอุโมงค์ขึ้น และควรอยู่ในสคริปต์ข้างไคลเอนต์ไม่ใช่ในเชลล์ที่คุณจะลืม มันไม่สามารถให้การเข้าถึงที่อยู่เดียวกันบนสองเครือข่ายพร้อมกันได้ และข้อจำกัดนั้นคือสิ่งที่ส่งคนอื่นลงไปตามตาราง
การเปลี่ยนเลข LAN ที่บ้าน เป็น 10.10.0.0/24 คือทางแก้ที่สะอาด: ต่ออายุสัญญา DHCP หนึ่งครั้งพร้อมการจอง คิวพิมพ์ และที่อยู่ที่เขียนตายตัวซึ่งอ้างช่วงเก่า การเปลี่ยนเลขฝั่งออฟฟิศมักไม่ใช่การตัดสินใจของคุณ IPv6 ขจัดความขัดแย้งทั้งหมดเมื่อทั้งสองเครือข่ายรองรับ โดยใช้คำนำหน้าโลคัลเฉพาะจาก fd00::/8 แทนสิ่งที่จำง่าย แต่ทดสอบแอปพลิเคชันผ่าน TCP ไม่ใช่ ping เพราะ ICMP อาจใช้ได้ขณะที่บริการใช้ไม่ได้
ตัวเลือกแปลของ OpenVPN เองเป็นทางสุดท้าย ถูกส่งจากเซิร์ฟเวอร์ไปยังรายการไดเรกทอรีเฉพาะไคลเอนต์ รับพารามิเตอร์สี่ตัวหลังชื่อตัวเลือก — ทิศทาง เครือข่าย เน็ตมาสก์ และนามแฝง — และนามแฝงไม่ใช่ทางเลือก: push "route 192.168.2.0 255.255.255.0" และ push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0" เครือข่ายและเน็ตมาสก์คือช่วงที่ไคลเอนต์เห็น (192.168.2.0/24) นามแฝงคือช่วงออฟฟิศจริงฝั่งเซิร์ฟเวอร์ (192.168.1.0/24) และเส้นทางที่ส่งมาคือสิ่งที่ทำให้ช่วงที่มองเห็นนั้นเข้าถึงได้ ออฟฟิศจะปรากฏต่อไคลเอนต์นั้นภายใต้ 192.168.2.x จดบันทึกการแมปในโปรไฟล์ ไม่เช่นนั้นคนถัดไปจะดีบักเป็นความผิดพลาดของเส้นทาง
การเผยแพร่บริการเดียวคือเวอร์ชันแคบของการแปล และไม่ต้องใช้ตัวเลือกของ OpenVPN เลย กฎ DNAT บนโฮสต์ VPN เผยแพร่พอร์ตเดียวอีกครั้ง LAN จึงเก็บที่อยู่ของมันไว้และเข้าถึงบริการที่ที่อยู่โฮสต์ที่รู้อยู่แล้ว ต้นทุนคือแบบปกติ: บริการเห็นโฮสต์ VPN เป็นต้นทาง บันทึกต่อไคลเอนต์และการค้นย้อนกลับจึงไม่มีความหมายอีก สิ่งนี้ครอบคลุมคิวพิมพ์หนึ่งคิวหรือหน้าผู้ดูแลหนึ่งหน้า ไม่ใช่โฮสต์สองฝั่งที่เข้าถึงกัน
อะไรจะยังใช้ไม่ได้ และต้องบันทึกอะไร
การแพร่กระจายไม่ข้ามอุโมงค์ที่กำหนดเส้นทาง DLNA, UPnP, การท่อง NetBIOS และ Wake-on-LAN ขึ้นกับการแพร่กระจายหรือมัลติแคสต์ที่อุปกรณ์ tun ไม่ได้พาไป จึงไม่มีเส้นทางใดแก้การค้นพบได้ การบริดจ์ด้วย dev tap ขยายเซกเมนต์ และขยายการแพร่กระจาย DHCP, ARP และแพ็กเก็ตการค้นพบอื่น ๆ ไปด้วย ควรเลือกเส้นทางโฮสต์แบบยูนิแคสต์เช่น route 192.168.2.1 255.255.255.255 สำหรับที่อยู่ฝั่ง LAN ของเราเตอร์ระยะไกล
เราเตอร์สองตัวที่ใช้ 192.168.1.1 บนเส้นทางเดียวกันเป็นปัญหาแบบเดียวกัน: ที่อยู่ในเครื่องชนะเสมอ หน้าของเราเตอร์ไกลจึงเข้าถึงไม่ได้จนกว่าจะย้าย LAN หนึ่งตัว การเพิ่มอะแดปเตอร์ตัวที่สองไม่เปลี่ยนอะไรในทั้งสองกรณี
บันทึกหลักฐานก่อนแก้ไขสิ่งใด: ip route get หรือ Find-NetRoute, ping -c 3 ไปยังที่อยู่ที่สงสัย, traceroute, และ tcpdump -ni tun0 icmp บนไคลเอนต์ จากนั้นตารางเส้นทางและตัวนับ NAT บนเซิร์ฟเวอร์ ping ที่ใช้ได้ทางหนึ่งและตายอีกทางชี้ไปที่ทางกลับ ไม่ใช่อุโมงค์ และความแตกต่างเดียวนี้ตัดสินว่าการซ่อมแบบใดข้างต้นที่คุณต้องการจริง ๆ