VPN và LAN trong nhà dùng chung một subnet: đi theo tuyến trước
Cả hai adapter đều nhận 192.168.1.0/24 và chỉ một tuyến thắng. Đi qua danh sách adapter, tuyến thắng và đường về trước khi đánh số lại hoặc đổ lỗi cho DNS.
Bạn kết nối VPN của công ty, biểu tượng trên khay chuyển xanh, intranet tải được, và chiếc máy in cách hai mét ngừng phản hồi. Thư mục chia sẻ chạy được buổi sáng nay lại hết thời gian trên chính máy đó, và không bản ghi nào nhắc tới máy in. Phản xạ đầu tiên là DNS, vì một cái tên không phân giải được trông giống cái tên không tồn tại, nhưng vấn đề nằm ở địa chỉ: hai adapter giờ cùng nhận 192.168.1.0/24 và chỉ một tuyến có thể thắng tiền tố đó. Đi theo đúng thứ tự này và bạn sẽ thấy adapter nào đã chiếm nó trước khi thay đổi bất cứ điều gì.
Bắt đầu từ triệu chứng, không phải từ đường hầm
Manh mối là phạm vi. Nếu intranet chạy mà mọi thiết bị nội bộ đều hỏng, đường hầm lành và đường nội bộ thì không. Nếu thiết bị nội bộ chạy mà intranet hỏng, thì ngược lại. Nếu mọi thứ chạy trừ một máy, bạn đang nhìn một địa chỉ tồn tại ở cả hai phía.
Ghi ra một địa chỉ nội bộ và một địa chỉ từ xa trước khi chạm vào cấu hình. “Máy in” không kiểm tra được; 192.168.1.40 thì được. Bước đó ngăn được giờ đồng hồ mất nhiều nhất trong vấn đề này, tức là viết lại cấu hình DNS vì một quyết định định tuyến.
Bước 1: xem cả hai adapter cùng nhận tiền tố
Mở Kết nối mạng (ncpa.cpl) và đọc hai adapter cạnh nhau. Adapter Ethernet hiển thị 192.168.1.50/24 với gateway 192.168.1.1. Adapter VPN hiển thị 192.168.1.201/24 do máy chủ đẩy xuống. Cả hai đều hợp lệ, cả hai đều tin tiền tố là on-link, và ngăn xếp sẽ chỉ giữ một tuyến cho nó.
Get-NetIPAddress -AddressFamily IPv4 liệt kê các địa chỉ, và Get-NetIPInterface | Sort-Object InterfaceMetric hiển thị thứ tự ngăn xếp sẽ dùng chúng. Cột metric đó chính là quyết định bạn sắp đọc, nên hãy ghi số ra thay vì cố nhớ.
Phản bác giả thuyết DNS với chi phí thấp: Resolve-DnsName printer.office.lan trả về đúng địa chỉ của hôm qua. Tên đã phân giải được; sau đó gói tin đi ra qua adapter sai. Hai phút ở đây tiết kiệm cả buổi chiều trong cấu hình trình phân giải.
Bước 2: đọc tuyến thực sự thắng
Find-NetRoute -RemoteIPAddress 192.168.1.40 in ra giao diện, bước nhảy kế tiếp và nguồn mà ngăn xếp sẽ dùng cho địa chỉ đó. Hãy coi kết quả đó là câu trả lời, không phải gợi ý. route print -4 cho toàn bộ bảng khi bạn muốn thấy mục nào đã thua và thua bao nhiêu.
Tính đặc thù thắng ý định. Một 192.168.0.0/25 được đẩy xuống thắng 192.168.0.0/24 nội bộ vì tiền tố dài hơn, nên 192.168.0.0 đến 192.168.0.127 đi ra qua đường hầm trong khi nửa trên vẫn ở nội bộ. Việc nửa mạng LAN biến mất mà không có thông báo lỗi là hành vi đúng của bảng đó.
tracert -d 192.168.1.40 xác nhận điều này từ ngoài bảng: nếu bước nhảy đầu tiên là địa chỉ đường hầm thay vì router của bạn, thì tuyến chính là toàn bộ câu chuyện. Trên Linux câu hỏi đó là ip route get 192.168.1.40, in ra địa chỉ nguồn và thiết bị trên một dòng. Khi câu trả lời nêu tun0, hãy ngừng nhìn vào trình duyệt.
Bước 3: kiểm tra đường về trước khi đổ lỗi cho máy khách
Tuyến đi đúng vẫn hỏng nếu phía xa không trả lời được. Khi tới LAN của máy khách qua đường hầm, gateway của LAN đó phải biết pool đường hầm nằm ở đâu: ip route add 10.8.0.0/24 via 192.168.1.12 trên router đó, và push “route 192.168.1.0 255.255.255.0” từ máy chủ để máy khách biết đường về.
Không có mục đầu tiên, gói trả lời rời đích đi về gateway mặc định của nó, nơi chuyển một địa chỉ riêng tới nhà cung cấp và bỏ nó. Triệu chứng một chiều và dễ đọc sai: yêu cầu hiện trên tun0, trả lời thì không bao giờ.
Một luật masquerade trên máy chủ VPN loại bỏ nhu cầu về tuyến tĩnh đó: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. Nó cũng che địa chỉ nguồn thật, khiến mọi câu hỏi log về sau khó hơn. Một máy đích có gateway mặc định sai tạo ra sự im lặng tương tự, tốt nhất là chuyển hướng ICMP và thường là hố đen, nên việc bắt gói cần ở cả hai đầu.
Bước 4: chọn cách sửa bạn sống được cùng
Có năm cách sửa cho việc này và chúng không thay thế được cho nhau. Chọn theo điều gì phải còn truy cập được cùng lúc, không theo lệnh nào ngắn nhất.
| 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 |
Metric là lựa chọn rẻ và là thứ người ta nhắm tới trước. Thay đổi áp lên giao diện, nên có tác dụng khi đường hầm đang lên, và chỗ của nó là trong script cạnh máy khách chứ không phải trong shell bạn sẽ quên. Nó không thể cho truy cập đồng thời cùng một địa chỉ trên hai mạng, và chính giới hạn đó đẩy những cách còn lại xuống dưới bảng.
Đánh số lại LAN trong nhà sang 10.10.0.0/24 là cách sạch: một lần gia hạn DHCP cùng các đặt trước, hàng đợi in và địa chỉ viết cứng có nhắc dải cũ. Đánh số lại phía công ty thường không phải quyết định của bạn. IPv6 loại bỏ hoàn toàn xung đột khi cả hai mạng hỗ trợ, dùng tiền tố cục bộ duy nhất từ fd00::/8 thay cho thứ dễ nhớ, nhưng hãy kiểm tra ứng dụng qua TCP chứ không phải ping, vì ICMP có thể chạy trong khi dịch vụ thì không.
Tùy chọn chuyển đổi riêng của OpenVPN là phương án cuối, được đẩy từ máy chủ vào mục thư mục riêng cho máy khách. Nó nhận bốn tham số sau tên tùy chọn — hướng, mạng, mặt nạ và bí danh — và bí danh không phải tùy chọn: push "route 192.168.2.0 255.255.255.0" và push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0". Mạng và mặt nạ là dải máy khách nhìn thấy (192.168.2.0/24), bí danh là dải công ty thật ở phía máy chủ (192.168.1.0/24), và tuyến được đẩy xuống làm cho dải nhìn thấy đó truy cập được. Công ty khi đó hiện ra với máy khách ấy dưới 192.168.2.x. Ghi lại ánh xạ trong hồ sơ, nếu không người sau sẽ gỡ lỗi nó như một sự cố định tuyến.
Chỉ công bố một dịch vụ là phiên bản hẹp của chuyển đổi, và nó không cần tùy chọn OpenVPN chút nào. Một luật DNAT trên máy chủ VPN công bố lại một cổng, nên LAN giữ địa chỉ của mình và tới dịch vụ ở địa chỉ máy mà nó đã biết. Cái giá là thường lệ: dịch vụ thấy máy chủ VPN là nguồn, nên log theo từng máy khách và tra cứu ngược không còn ý nghĩa. Nó phủ một hàng đợi in hoặc một trang quản trị, không phải các máy hai bên tới được nhau.
Điều gì vẫn sẽ không chạy, và cần ghi lại gì
Quảng bá không đi qua đường hầm có định tuyến. DLNA, UPnP, duyệt NetBIOS và Wake-on-LAN phụ thuộc quảng bá hoặc multicast mà thiết bị tun không mang, nên không tuyến nào sửa được việc phát hiện. Cầu nối với dev tap kéo dài đoạn mạng, cùng với nó là quảng bá DHCP, ARP và mọi gói phát hiện khác; hãy ưu tiên tuyến máy unicast như route 192.168.2.1 255.255.255.255 cho địa chỉ phía LAN của một router từ xa.
Hai router cùng dùng 192.168.1.1 trên cùng một đường thuộc cùng một họ vấn đề: địa chỉ nội bộ luôn thắng, nên trang của router xa vẫn không tới được cho tới khi một LAN chuyển đi. Thêm adapter thứ hai không thay đổi gì trong cả hai trường hợp.
Ghi lại bằng chứng trước khi sửa bất cứ thứ gì: ip route get hoặc Find-NetRoute, ping -c 3 tới địa chỉ liên quan, một traceroute, và tcpdump -ni tun0 icmp trên máy khách, sau đó bảng định tuyến và bộ đếm NAT trên máy chủ. Một ping chạy được một chiều và chết ở chiều kia chỉ ra đường về chứ không phải đường hầm, và chính khác biệt đó quyết định cách sửa nào ở trên bạn thật sự cần.