Ingen rutt reparerar en VPN-pool som överlappar ditt LAN

Appen hävdar att tunneln är frisk, och ändå svarar hälften av de destinationer du behöver aldrig. Reflexen är att lägga till en rutt eller sänka ett metric-värde, och just den reflexen är myten som bör dödas först. När klientens eget LAN och tunnelns pool gör anspråk på samma prefix håller routingtabellen två oförenliga fakta, och varken en standardrutt eller ett metric-värde löser dem. Reparationen är ett adresseringsbeslut, och ingen ruttredigering ersätter den.

Varför en extra rutt inte kan dela ett prefix

En rutt kan inte skilja två anspråk på ett prefix, därför är det kloka draget att sluta leta efter rätt ruttrad. Stacken placerar inte ett identiskt prefix före den anslutna rutten, och en mer specifik post fångar adressen, men gör den lokala värd som äger den onåbar. Det som ser ut som ett routingproblem är en adresseringskollision, och båda reparationerna ändrar adresser i stället för rutter. Testa påståendet på din egen maskin innan du accepterar det.

ip route get 192.168.1.50
route -n get 192.168.1.50
Find-NetRoute -RemoteIPAddress 192.168.1.50

Fråga systemet om en enda adress och notera vilket gränssnitt det namnger. Linux, macOS och Windows svarar var och en med en skrivskyddad uppslagning som rapporterar det valda gränssnittet och nästa hopp utan att skicka något. När svaret pekar på den fysiska adaptern medan tunneln är uppe behandlar kärnan adressen som on-link och inte som något tunneln skulle kunna bära.

Sätt prefixet som leverantören tilldelat bredvid det som hemmaroutern betjänar och jämför dem som strängar. Exakt överensstämmelse är det tydliga fallet, och en bredare leverantörspool som innehåller hemmanätet misslyckas likadant, men är lättare att missa. Två prefix som bara ser lika ut är ingen kollision, så skriv ned båda innan du ändrar något.

Läs poolen som klienten faktiskt fick

Läs vad klienten tog emot, inte leverantörens marknadsföringssida. Höj detaljnivån i loggen för en OpenVPN-klient och rutterna som servern skjuter på visas i den och avslöjar tunnelns prefix; på andra ställen dyker poolen upp i anslutningsinformationen eller på adaptern själv. Be leverantören om den fullständiga listan över privata intervall som den använder, för ett enda /24 i dag kan vara två i morgon. Att undvika de vanliga RFC 1918-blocken är inte samma sak som att undvika den tilldelning du faktiskt fått.

En pool kan också krympa eller flytta mellan regioner, så listan behöver ett datum och en ägare. Behandla varje leverantörssvar som är äldre än din senaste planändring som en gissning, inte ett faktum. Fråga igen innan du binder dig till ett intervall, och spara svaret med nätverksanteckningarna så att nästa person ärver beviset.

Omnumrering är reparationen du kan göra

Om VPN-servern inte är din att ändra, är flytten av hemma-LAN-et den enda tillgängliga reparationen, och det är det vanliga läget med en kommersiell leverantör. Välj ett intervall utanför leverantörens pool och utanför de intervall du kan behöva senare, och kontrollera det mot varje annan plats du når via en tunnel. Räkna med ett kort avbrott och en längre svans av bortglömda enheter: en enhet som fortfarande har den gamla adressen verkar fungera tills den behöver gatewayen.

1. Först inventering: routerns egen adress, DHCP-området, reservationer, portvidarebefordringar och varje enhet vars adress skrivits in för hand.
2. Ändra sedan routerns LAN-prefix och DHCP-området tillsammans inom ett underhållsfönster, och förnya trådbundna leases före trådlösa.
3. Rätta därefter de statiska adresserna: skrivare, nätverkslagring, allt med en hårdkodad gateway.
4. Anslut till sist VPN-klienten igen och bekräfta att tunneladressen inte längre krockar med LAN-et.

Gå igenom adresserna i den ordningen i stället för alla på en gång, och håll det gamla intervallet dokumenterat ett tag så att en föråldrad enhet går att känna igen i stället för att vara mystisk. En enhet som aldrig förnyar anmäler sig genom att inte nå gatewayen, vilket är ett mycket bättre spår än ett samtal till supporten. Om routern delar ut leases som är längre än ett dygn, förkorta dem under fönstrets längd.

Vad ett alias kan och inte kan

När servern är din kan översättning av adresser på klienten blotta det avlägsna prefixet inom ett ledigt lokalt intervall, så att samma värd svarar på en andra adress. Community-OpenVPN gör det med client-nat, och den direktivet är specifik för den klienten, frånvarande i de kommersiella och mobila klienter som folk vanligen jämför den med. Upplägget kräver en rutt som matchar översättningen, ett ledigt intervall för aliaset och en server som är villig att svara på klientens oöversatta adress. Inget av det hjälper när klienten tillhör en hanterad leverantör som du inte kan konfigurera.

När ändringen är på plats, nå en lokal värd och en avlägsen värd först på adress och sedan på namn, och notera rutten som systemet väljer varje gång. Ett namn kan fortfarande lösas upp i det gamla intervallet, så adresser och namn förtjänar oberoende kontroller. Starta om en klient och en enhet på serversidan om någon av dem stod kvar genom ändringen, eftersom cachade granne-poster lever längre än redigeringen.

Skriv ned prefixen du landade i där folk faktiskt tittar: nätverksanteckningarna, routerns eget kommentarsfält, introduktionssidan. Någon väljer 192.168.1.0/24 igen, och kollisionen kommer tillbaka med dem.