VPN en tuis-LAN op dieselfde subnet: stap eers die roete na

Jy koppel aan die kantoor se VPN, die ikoon in die systeemlaai word groen, die intranet laai, en die drukker twee meter verder hou op antwoord. Die deel wat vanoggend gewerk het, verstryk op dieselfde masjien, en nêrens in enige log staan iets oor ’n drukker nie. Die refleks is DNS, want ’n naam wat nie oplos nie, lyk soos ’n naam wat nie bestaan nie, maar die adres is die probleem: twee adapters eis nou 192.168.1.0/24 en net een roete kan daardie voorvoegsel wen. Stap dit in hierdie volgorde deur, en jy sal sien watter adapter dit gevat het voordat jy enigiets verander.

Begin by die simptoom, nie by die tonnel nie

Die aanduiding is omvang. As die intranet werk en elke plaaslike toestel faal, is die tonnel gesond en die plaaslike pad nie. As plaaslike toestelle werk en die intranet faal, is dit die omgekeerde. As alles werk behalwe een gasheer, kyk jy na ’n enkele adres wat aan beide kante bestaan.

Skryf een plaaslike adres en een afgeleë adres neer voordat jy aan ’n instelling raak. “Die drukker” is nie toetsbaar nie; 192.168.1.40 is. Daardie een stap voorkom die mees algemene vermorste uur op hierdie probleem, naamlik om DNS-instellings te herskryf vir ’n roetebesluit.

Stap 1: sien albei adapters wat die voorvoegsel eis

Maak Netwerkverbindings (ncpa.cpl) oop en lees die twee adapters langs mekaar. Die Ethernet-adapter wys 192.168.1.50/24 met gateway 192.168.1.1. Die VPN-adapter wys 192.168.1.201/24, deur die bediener gestuur. Albei is wettig, albei glo die voorvoegsel is on-link, en die stapel sal ’n enkele roete daarby hou.

Get-NetIPAddress -AddressFamily IPv4 lys die adresse, en Get-NetIPInterface | Sort-Object InterfaceMetric wys die volgorde waarin die stapel hulle sal gebruik. Daardie metriekkolom is die besluit wat jy op die punt staan om te lees, so skryf die nommers neer eerder as om hulle te probeer onthou.

Bewys die DNS-teorie goedkoop verkeerd: Resolve-DnsName printer.office.lan gee dieselfde adres terug as gister. Die naam het opgelos; die pakkie het toe deur die verkeerde adapter vertrek. Twee minute hier spaar ’n middag in resolver-instellings.

Stap 2: lees die roete wat werklik gewen het

Find-NetRoute -RemoteIPAddress 192.168.1.40 druk die koppelvlak, volgende sprong en bron wat die stapel vir daardie adres sou gebruik. Behandel daardie uitset as die antwoord, nie as ’n wenk nie. route print -4 gee die hele tabel wanneer jy wil sien watter inskrywing verloor het en met hoeveel.

Spesifisiteit wen van bedoeling. ’n Gestuurde 192.168.0.0/25 verslaan ’n plaaslike 192.168.0.0/24 omdat die voorvoegsel langer is, so 192.168.0.0 tot 192.168.0.127 verlaat deur die tonnel terwyl die boonste helfte plaaslik bly. ’n Halwe LAN wat sonder ’n foutboodskap verdwyn, is korrekte gedrag vir daardie tabel.

tracert -d 192.168.1.40 bevestig dit van buite die tabel: as die eerste sprong ’n tonneladres is eerder as jou eie router, is die roete die hele storie. Op Linux is dieselfde vraag ip route get 192.168.1.40, wat bronadres en toestel op een lyn druk. Wanneer die antwoord tun0 noem, hou op om na die blaaier te kyk.

Stap 3: kyk na die terugpad voordat jy die kliënt blameer

’n Korrekte vorentoe-roete faal steeds as die ver kant nie kan antwoord nie. Wanneer ’n kliënt-LAN deur die tonnel bereik word, moet die LAN-gateway weet waar die tonnelpoel woon: ip route add 10.8.0.0/24 via 192.168.1.12 op daardie router, en push “route 192.168.1.0 255.255.255.0” vanaf die bediener sodat kliënte die terugpad ken.

Sonder die eerste inskrywing verlaat die antwoord die teiken na sy verstek-gateway, wat ’n private adres aan die ISP oorhandig en dit laat val. Die simptoom is eenrigting en maklik om verkeerd te lees: versoeke verskyn op tun0, antwoorde nooit nie.

’n Masquerade-reël op die VPN-gasheer verwyder die behoefte aan daardie statiese roete: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. Dit verberg ook die werklike bronadresse, wat elke latere logvraag moeiliker maak. ’n Teikengasheer met die verkeerde verstek-gateway lewer dieselfde stilte, met ’n ICMP-omleiding as die beste geval en ’n swart gat as die normale een, en daarom hoort die opname aan beide kante.

Stap 4: kies ’n herstel waarmee jy kan saamleef

Vyf herstellings word hiervoor gebruik, en hulle is nie uitruilbaar nie. Kies volgens wat op dieselfde tyd bereikbaar moet bly, nie volgens watter opdrag die kortste is nie.

Metrieke is die goedkoop opsie en die een waarna mense eerste gryp. Die verandering geld vir die koppelvlak, so dit werk terwyl die tonnel op is, en dit hoort in ’n script langs die kliënt eerder as in ’n shell wat jy sal vergeet. Dit kan nie gelyktydige toegang tot dieselfde adres op twee netwerke gee nie, en dit is die beperking wat almal verder in die tabel afstuur.

Herommer die tuis-LAN na 10.10.0.0/24 is die skoon oplossing: een DHCP-huurvernuwing plus die reserverings, drukkerreekse en hardgekodeerde adresse wat die ou reeks noem. Om die kantoor se kant te herommer is gewoonlik nie jou besluit nie. IPv6 verwyder die botsing heeltemal wanneer albei netwerke dit dra, met ’n unieke plaaslike voorvoegsel uit fd00::/8 eerder as iets maklik onthoubaar, maar toets die toepassing oor TCP, nie met ’n ping nie, want ICMP kan werk terwyl die diens dit nie doen nie.

OpenVPN se eie vertalingsopsie is die laaste uitweg, van die bediener af in ’n kliëntspesifieke gidsinskrywing gestuur. Dit neem vier parameters ná die opsienaam — rigting, netwerk, netmasker en alias — en die alias is nie opsioneel nie: push "route 192.168.2.0 255.255.255.0" en push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0". Die netwerk en netmasker is die reeks wat die kliënt sien (192.168.2.0/24), die alias is die werklike kantoorreeks aan die bedienerkant (192.168.1.0/24), en die gestuurde roete is wat daardie sigbare reeks bereikbaar maak. Die kantoor verskyn dan vir daardie kliënt onder 192.168.2.x. Dokumenteer die kartering in die profiel, anders sal die volgende persoon dit as ’n roetefout ontspan.

Om ’n enkele diens te publiseer is die nou weergawe van vertaal, en dit het glad nie OpenVPN se opsie nodig nie. ’n DNAT-reël op die VPN-gasheer herpubliseer een poort, so die LAN hou sy adresse en bereik die diens by die gasheeradres wat hy reeds ken. Die koste is die gewone een: die diens sien die VPN-gasheer as die bron, so logs per kliënt en omgekeerde opsoeke beteken niks meer nie. Dit dek een drukkerreeks of een admin-blad, nie gashere aan beide kante wat mekaar bereik nie.

Wat steeds nie sal werk nie, en wat om aan te teken

Uitsaai gaan nie oor ’n gerouteerde tonnel nie. DLNA, UPnP, NetBIOS-blaaiery en Wake-on-LAN hang af van uitsaai of multicast wat ’n tun-toestel nie dra nie, so geen roete herstel ontdekking nie. Oorbrugging met dev tap verleng die segment, en daarmee saam DHCP-uitsendings, ARP en elke ander ontdekkingspakkie; verkies ’n unicast-gasheerroete soos route 192.168.2.1 255.255.255.255 vir die LAN-kant-adres van ’n afgeleë router.

Twee routers wat albei 192.168.1.1 op dieselfde pad gebruik, hoort tot dieselfde familie probleem: die plaaslike adres wen altyd, so die ver router se bladsy bly onbereikbaar totdat een LAN skuif. Om ’n tweede adapter by te voeg, verander niks aan enige van die twee gevalle nie.

Teken die bewyse aan voordat jy enigiets wysig: ip route get of Find-NetRoute, ping -c 3 na die betrokke adres, ’n traceroute, en tcpdump -ni tun0 icmp op die kliënt, dan die roetetabel en NAT-tellers op die bediener. ’n Ping wat eenkant werk en anderkant doodgaan, wys na die terugpad, nie na die tonnel nie, en daardie enkele onderskeid besluit watter van die herstellings hierbo jy werklik nodig het.