VPN och hemnätet på samma subnät: följ rutten först
Båda adaptrarna gör anspråk på 192.168.1.0/24 och bara en rutt vinner. Följ adapterlistan, den vinnande rutten och returvägen innan du numrerar om eller skyller på DNS.
Du ansluter till kontorets VPN, ikonen i aktivitetsfältet blir grön, intranätet laddas och skrivaren två meter bort slutar svara. Den delade mappen som fungerade i morse får tidsgräns på samma maskin, och ingen logg nämner en skrivare. Refleksen är DNS, eftersom ett namn som inte löses upp ser ut som ett namn som inte finns, men problemet är adressen: två adaptrar gör nu anspråk på 192.168.1.0/24 och bara en rutt kan vinna det prefixet. Följ det i den här ordningen och du ser vilken adapter som tog det innan du ändrar något.
Börja vid symtomet, inte vid tunneln
Tecknet är omfattningen. Om intranätet fungerar och varje lokal enhet misslyckas är tunneln frisk och den lokala vägen inte. Om lokala enheter fungerar och intranätet misslyckas är det tvärtom. Om allt fungerar utom en värd tittar du på en enda adress som finns på båda sidor.
Skriv ned en lokal och en avlägsen adress innan du rör en inställning. ”Skrivaren” går inte att testa; 192.168.1.40 går. Det enda steget hindrar den vanligaste bortkastade timmen i det här problemet, nämligen att skriva om DNS-inställningar för ett routingbeslut.
Steg 1: se båda adaptrarna göra anspråk på prefixet
Öppna Nätverksanslutningar (ncpa.cpl) och läs de två adaptrarna sida vid sida. Ethernet-adaptern visar 192.168.1.50/24 med gateway 192.168.1.1. VPN-adaptern visar 192.168.1.201/24, skickad av servern. Båda är legitima, båda tror att prefixet är on-link, och stacken håller en enda rutt för det.
Get-NetIPAddress -AddressFamily IPv4 listar adresserna, och Get-NetIPInterface | Sort-Object InterfaceMetric visar ordningen som stacken använder dem i. Den metrikkolumnen är beslutet du är på väg att läsa, så skriv ned siffrorna i stället för att försöka komma ihåg dem.
Motbevisa DNS-teorin billigt: Resolve-DnsName printer.office.lan returnerar samma adress som i går. Namnet löstes upp; sedan lämnade paketet den felaktiga adaptern. Två minuter här sparar en eftermiddag i resolverinställningar.
Steg 2: läs rutten som faktiskt vann
Find-NetRoute -RemoteIPAddress 192.168.1.40 skriver ut gränssnittet, nästa hopp och den källa som stacken skulle använda för den adressen. Behandla utdata som svaret, inte som en ledtråd. route print -4 ger hela tabellen när du vill se vilken post som förlorade och med hur mycket.
Specificitet slår avsikt. En pushad 192.168.0.0/25 slår en lokal 192.168.0.0/24 eftersom prefixet är längre, så 192.168.0.0 till 192.168.0.127 går ut genom tunneln medan den övre halvan stannar lokalt. Att ett halvt nätverk försvinner utan felmeddelande är rätt beteende för den tabellen.
tracert -d 192.168.1.40 bekräftar det utanför tabellen: om första hoppet är en tunneladress i stället för din egen router är rutten hela historien. På Linux är samma fråga ip route get 192.168.1.40, som skriver källadress och enhet på en rad. När svaret nämner tun0, sluta titta på webbläsaren.
Steg 3: kontrollera returvägen innan du skyller på klienten
En korrekt rutt framåt misslyckas ändå om den bortre sidan inte kan svara. När ett klientnätverk nås genom tunneln måste gatewayen i det nätverket veta var tunnelpoolen bor: ip route add 10.8.0.0/24 via 192.168.1.12 på den routern, och push ”route 192.168.1.0 255.255.255.0” från servern så att klienterna känner till returvägen.
Utan den första posten lämnar svaret målet mot sin standardgateway, som vidarebefordrar en privat adress till leverantören och tappar den. Symtomet är enkelriktat och lätt att läsa fel: förfrågningar dyker upp på tun0, svar aldrig.
En masquerade-regel på VPN-värden tar bort behovet av den statiska rutten: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. Den döljer också de verkliga källadresserna, vilket gör varje senare loggfråga svårare. En målvärd med fel standardgateway ger samma tystnad, med en ICMP-omdirigering i bästa fall och ett svart hål i det normala, och därför hör fångsten hemma i båda ändar.
Steg 4: välj en reparation du kan leva med
Det används fem reparationer för detta, och de är inte utbytbara. Välj efter vad som måste förbli nåbart samtidigt, inte efter vilket kommando som är kortast.
| 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 |
Metriker är det billiga alternativet och det som folk griper efter först. Ändringen gäller gränssnittet, så den fungerar medan tunneln är uppe, och den hör hemma i ett skript bredvid klienten i stället för i ett skal som du glömmer. Den kan inte ge samtidig åtkomst till samma adress på två nätverk, och det är gränsen som skickar alla andra nedåt i tabellen.
Omnumrering av hemnätet till 10.10.0.0/24 är den rena lösningen: en DHCP-leaseförnyelse plus reservationerna, skrivarköerna och de hårdkodade adresserna som nämner det gamla intervallet. Omnumrering av kontorssidan är vanligtvis inte ditt beslut. IPv6 tar bort kollisionen helt när båda näten bär det, med ett unikt lokalt prefix från fd00::/8 i stället för något minnesvärt, men testa applikationen över TCP, inte med ping, eftersom ICMP kan fungera medan tjänsten inte gör det.
OpenVPN:s egen översättningsoption är den sista utvägen, pushad från servern in i en klientspecifik katalogpost. Den tar fyra parametrar efter optionsnamnet — riktning, nätverk, nätmask och alias — och aliaset är inte valfritt: push "route 192.168.2.0 255.255.255.0" och push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0". Nätverket och masken är intervallet som klienten ser (192.168.2.0/24), aliaset är det verkliga kontorsintervallet på serversidan (192.168.1.0/24), och den pushade rutten är det som gör det synliga intervallet nåbart. Kontoret framträder då för den klienten under 192.168.2.x. Dokumentera mappningen i profilen, annars felsöker nästa person det som ett routingfel.
Att publicera en enda tjänst är den smala versionen av översättning, och den behöver inte OpenVPN:s option alls. En DNAT-regel på VPN-värden publicerar om en enda port, så nätverket behåller sina adresser och når tjänsten på den värdadress det redan känner till. Kostnaden är den vanliga: tjänsten ser VPN-värden som källa, så loggar per klient och omvända uppslag slutar betyda något. Det täcker en skrivarkö eller en administratörssida, inte värdar på båda sidor som når varandra.
Vad som fortfarande inte kommer att fungera, och vad som ska antecknas
Broadcast korsar inte en routad tunnel. DLNA, UPnP, NetBIOS-bläddring och Wake-on-LAN bygger på broadcast eller multicast som en tun-enhet inte bär, så ingen rutt reparerar upptäckten. Bryggning med dev tap förlänger segmentet, och med det DHCP-broadcast, ARP och varje annat upptäcktspaket; föredra en unicast-värdrutt som route 192.168.2.1 255.255.255.255 för LAN-sida adressen hos en avlägsen router.
Två routrar som båda använder 192.168.1.1 på samma väg tillhör samma familj av problem: den lokala adressen vinner alltid, så den bortre routerns sida förblir onåbar tills ett nätverk flyttar. Att lägga till en andra adapter ändrar ingenting i något av fallen.
Anteckna bevisen innan du redigerar något: ip route get eller Find-NetRoute, ping -c 3 till adressen i fråga, en traceroute, och tcpdump -ni tun0 icmp på klienten, sedan routingtabellen och NAT-räknarna på servern. En ping som fungerar ena vägen och dör den andra pekar på returvägen, inte på tunneln, och just den skillnaden avgör vilken av reparationerna ovan du faktiskt behöver.