VPN at LAN ng bahay sa iisang subnet: sundan muna ang ruta
Ang dalawang adapter ay nag-aangkin ng 192.168.1.0/24 at isang ruta lang ang nananalo. Sundan ang listahan ng adapter, ang nanalong ruta at ang pagbabalik bago mag-renumber o sisihin ang DNS.
Kumokonekta ka sa VPN ng opisina, nagiging berde ang icon sa tray, naglo-load ang intranet, at tumitigil sa pagsagot ang printer na dalawang metro ang layo. Ang share na gumagana kaninang umaga ay nag-time out sa parehong makina, at walang log na nagbabanggit ng printer. Ang repleks ay DNS, dahil ang pangalang hindi nare-resolve ay mukhang pangalang wala, pero ang problema ay ang address: dalawang adapter na ang nag-aangkin ng 192.168.1.0/24 at isang ruta lang ang maaaring manalo sa prefix na iyon. Sundan ito sa ganitong pagkakasunod-sunod at makikita mo kung aling adapter ang kumuha bago ka magbago ng anuman.
Magsimula sa sintomas, hindi sa tunnel
Ang senyales ay saklaw. Kung gumagana ang intranet at bumabagsak ang bawat lokal na device, malusog ang tunnel at hindi ang lokal na landas. Kung gumagana ang lokal na device at bumabagsak ang intranet, kabaliktaran. Kung gumagana ang lahat maliban sa isang host, isang address lang na umiiral sa magkabilang panig ang tinitignan mo.
Isulat ang isang lokal at isang malayong address bago hawakan ang anumang setting. Hindi masusubok ang “printer”; masusubok ang 192.168.1.40. Ang isang hakbang na iyon ay pumipigil sa pinakakaraniwang nasasayang na oras sa problemang ito, ang muling pagsulat ng mga setting ng DNS para sa isang desisyon sa routing.
Hakbang 1: tingnan ang dalawang adapter na nag-aangkin ng prefix
Buksan ang Network Connections (ncpa.cpl) at basahin ang dalawang adapter nang magkatabi. Ipinapakita ng Ethernet adapter ang 192.168.1.50/24 na may gateway 192.168.1.1. Ipinapakita ng VPN adapter ang 192.168.1.201/24, na ipinadala ng server. Pareho silang lehitimo, parehong naniniwala na on-link ang prefix, at isang ruta lang ang itatabi ng stack para doon.
Inililista ng Get-NetIPAddress -AddressFamily IPv4 ang mga address, at ipinapakita ng Get-NetIPInterface | Sort-Object InterfaceMetric ang pagkakasunod-sunod ng paggamit ng stack. Ang column ng metric na iyon ang desisyong babasahin mo, kaya itala ang mga numero sa halip na kabisaduhin.
Pabulaanan ang teorya ng DNS nang mura: ibinabalik ng Resolve-DnsName printer.office.lan ang parehong address kahapon. Na-resolve ang pangalan; pagkatapos, lumabas ang packet sa maling adapter. Dalawang minuto dito ay nakakatipid ng isang hapon sa mga setting ng resolver.
Hakbang 2: basahin ang rutang tunay na nanalo
Ipinapakita ng Find-NetRoute -RemoteIPAddress 192.168.1.40 ang interface, susunod na hop at source na gagamitin ng stack para sa address na iyon. Ituring ang output na iyon na sagot, hindi pahiwatig. Ibinibigay ng route print -4 ang buong talahanayan kapag gusto mong makita kung aling entry ang natalo at gaano.
Ang pagiging tiyak ay nananalo sa intensyon. Ang itinulak na 192.168.0.0/25 ay tinalo ang lokal na 192.168.0.0/24 dahil mas mahaba ang prefix, kaya lumalabas ang 192.168.0.0 hanggang 192.168.0.127 sa tunnel habang nananatiling lokal ang itaas na kalahati. Ang paglaho ng kalahating LAN nang walang mensahe ng error ay tamang pag-uugali para sa talahanayang iyon.
Kinukumpirma ito ng tracert -d 192.168.1.40 mula sa labas ng talahanayan: kung ang unang hop ay address ng tunnel sa halip na ang sarili mong router, ang ruta ang buong kuwento. Sa Linux ang parehong tanong ay ip route get 192.168.1.40, na naglalabas ng source address at device sa isang linya. Kapag pinangalanan ng sagot ang tun0, tigilan ang pagtingin sa browser.
Hakbang 3: suriin ang pagbabalik bago sisihin ang kliyente
Ang tamang ruta pakanan ay nabibigo pa rin kung hindi makasagot ang malayong panig. Kapag naabot ang LAN ng kliyente sa tunnel, kailangang malaman ng gateway ng LAN na iyon kung nasaan ang pool ng tunnel: ip route add 10.8.0.0/24 via 192.168.1.12 sa router na iyon, at push “route 192.168.1.0 255.255.255.0” mula sa server upang malaman ng mga kliyente ang pagbabalik.
Kung wala ang unang entry, umaalis ang sagot sa target patungo sa default gateway nito, na nagpapasa ng pribadong address sa provider at inihuhulog ito. Ang sintomas ay isang direksyon lamang at madaling mabasa nang mali: lumilitaw ang mga request sa tun0, ang mga sagot ay hindi kailanman.
Ang panuntunang masquerade sa host ng VPN ay nag-aalis ng pangangailangan sa static na rutang iyon: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. Itinatago rin nito ang tunay na source address, na nagpapahirap sa bawat susunod na tanong sa log. Ang target host na may maling default gateway ay gumagawa ng parehong katahimikan, na may ICMP redirect sa pinakamainam at black hole sa karaniwan, kaya kailangan ang pagkuha sa magkabilang dulo.
Hakbang 4: pumili ng pag-aayos na kaya mong pakisamahan
Limang pag-aayos ang ginagamit dito, at hindi sila mapagpapalit. Pumili batay sa kung ano ang dapat manatiling maabot sa parehong oras, hindi sa kung aling utos ang pinakamaikli.
| 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 |
Ang metric ang murang opsyon at ang unang inaabot ng mga tao. Naaangkop ang pagbabago sa interface, kaya gumagana habang nakataas ang tunnel, at dapat itong nasa script sa tabi ng kliyente hindi sa shell na makakalimutan mo. Hindi ito makapagbibigay ng sabay na pag-access sa parehong address sa dalawang network, at ang limitasyong iyon ang nagpapadala sa lahat ng iba pababa ng talahanayan.
Ang muling pag-numero ng LAN ng bahay sa 10.10.0.0/24 ang malinis na solusyon: isang pag-renew ng DHCP lease kasama ang mga reservation, print queue at hard-coded na address na nagbabanggit ng lumang saklaw. Ang muling pag-numero sa panig ng opisina ay karaniwang hindi desisyon mo. Tinatanggal ng IPv6 ang banggaan nang tuluyan kapag parehong sinusuportahan ng dalawang network, gamit ang natatanging lokal na prefix mula sa fd00::/8 sa halip na isang bagay na madaling tandaan, ngunit subukan ang aplikasyon sa TCP, hindi ping, dahil maaaring gumana ang ICMP habang hindi ang serbisyo.
Ang sariling opsyon sa pagsasalin ng OpenVPN ang huling paraan, itinutulak mula sa server patungo sa entry ng directory na partikular sa kliyente. Kumukuha ito ng apat na parameter pagkatapos ng pangalan ng opsyon — direksyon, network, netmask at alias — at ang alias ay hindi opsyonal: push "route 192.168.2.0 255.255.255.0" at push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0". Ang network at netmask ang saklaw na nakikita ng kliyente (192.168.2.0/24), ang alias ang tunay na saklaw ng opisina sa panig ng server (192.168.1.0/24), at ang itinulak na ruta ang nagpapagana sa nakikitang saklaw na iyon. Lumilitaw ang opisina sa kliyenteng iyon sa ilalim ng 192.168.2.x. Idokumento ang pagmamapa sa profile, kung hindi ay i-debug ito ng susunod na tao bilang sira ng routing.
Ang pag-publish ng isang serbisyo lang ay ang makitid na bersyon ng pagsasalin, at hindi nito kailangan ang opsyon ng OpenVPN. Ang isang panuntunang DNAT sa host ng VPN ay muling naglalathala ng isang port, kaya pinapanatili ng LAN ang mga address nito at naaabot ang serbisyo sa host address na kilala na nito. Ang halaga ay ang karaniwan: nakikita ng serbisyo ang host ng VPN bilang source, kaya ang mga log per kliyente at reverse lookup ay wala nang kahulugan. Sakop nito ang isang print queue o isang admin page, hindi ang mga host sa magkabilang panig na nag-aabot sa isa't isa.
Ano ang hindi pa gagana, at ano ang itatala
Hindi tumatawid ang broadcast sa rutadong tunnel. Ang DLNA, UPnP, pag-browse ng NetBIOS at Wake-on-LAN ay nakadepende sa broadcast o multicast na hindi dinadala ng tun device, kaya walang ruta ang nag-aayos ng pagtuklas. Ang pag-bridge gamit ang dev tap ay nagpapahaba ng segment, at kasama nito ang broadcast ng DHCP, ARP at iba pang packet ng pagtuklas; mas mainam ang unicast host route tulad ng route 192.168.2.1 255.255.255.255 para sa address sa panig ng LAN ng malayong router.
Dalawang router na parehong gumagamit ng 192.168.1.1 sa iisang landas ay kabilang sa iisang pamilya ng problema: laging nananalo ang lokal na address, kaya nananatiling hindi maabot ang pahina ng malayong router hanggang may isang LAN na lumipat. Walang nababago ang pagdaragdag ng pangalawang adapter sa alinman sa dalawang kaso.
Itala ang ebidensya bago mag-edit ng anuman: ip route get o Find-NetRoute, ping -c 3 sa address na pinag-uusapan, isang traceroute, at tcpdump -ni tun0 icmp sa kliyente, pagkatapos ang routing table at NAT counters sa server. Ang ping na gumagana sa isang direksyon at namamatay sa kabila ay tumuturo sa pagbabalik, hindi sa tunnel, at ang nag-iisang pagkakaibang iyon ang nagpapasya kung alin sa mga pag-aayos sa itaas ang talagang kailangan mo.