Ingen rute reparerer en VPN-pool som overlapper med LAN-et ditt

Appen hevder at tunnelen er sunn, og likevel svarer halvparten av destinasjonene du trenger aldri. Refleksen er å legge til en rute eller senke en metrikk, og nettopp den refleksen er myten som bør drepes først. Når klientens eget LAN og tunnelpoolen krever samme prefiks, holder rutetabellen to uforenelige fakta, og verken en standardrute eller en metrikk løser dem. Reparasjonen er en adresseringsbeslutning, og ingen ruteredigering erstatter den.

Hvorfor en ekstra rute ikke kan dele ett prefiks

En rute kan ikke skille to krav på ett prefiks, derfor er det fornuftige trekket å slutte å lete etter riktig rutelinje. Stakken plasserer ikke et identisk prefiks foran den tilkoblede ruten, og en mer spesifikk oppføring fanger adressen, men gjør den lokale verten som eier den utilgjengelig. Det som ser ut som et rutingsproblem, er en adresseringskollisjon, og begge reparasjonene endrer adresser i stedet for ruter. Test påstanden på din egen maskin før du godtar den.

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

Spør systemet om én enkelt adresse og legg merke til hvilket grensesnitt det nevner. Linux, macOS og Windows svarer hver med et skrivebeskyttet oppslag som rapporterer det valgte grensesnittet og neste hopp uten å sende noe. Når svaret peker på den fysiske adapteren mens tunnelen er oppe, behandler kjernen adressen som on-link og ikke som noe tunnelen kunne bære.

Sett prefikset leverandøren har gitt ved siden av det hjemmeruteren betjener, og sammenlign dem som strenger. Eksakt samsvar er det klare tilfellet, og en bredere leverandørpool som inneholder hjemmesubnettet feiler likt, men er lettere å overse. To prefikser som bare ser like ut, er ikke en kollisjon, så skriv ned begge før du endrer noe.

Les poolen klienten faktisk fikk

Les hva klienten mottok, ikke leverandørens markedsføringsside. Skru opp detaljnivået i loggen til en OpenVPN-klient, og rutene serveren skyver på vises i den og avslører tunnelprefiksene; andre steder dukker poolen opp i tilkoblingsdetaljene eller på adapteren selv. Be leverandøren om hele listen over private områder den bruker, for ett enkelt /24 i dag kan være to i morgen. Å unngå de vanlige RFC 1918-blokkene er ikke det samme som å unngå tildelingen du faktisk har fått.

En pool kan også krympe eller flytte mellom regioner, så listen trenger en dato og en eier. Behandle ethvert leverandørsvar som er eldre enn din siste planendring som en gjetning, ikke et faktum. Spør igjen før du forplikter deg til et område, og ta vare på svaret sammen med nettverksnotatene slik at neste person arver beviset.

Omnummerering er reparasjonen du kan gjøre

Hvis VPN-serveren ikke er din å endre, er flytting av hjemme-LAN-et den eneste tilgjengelige reparasjonen, og det er den vanlige situasjonen med en kommersiell leverandør. Velg et område utenfor leverandørens pool og utenfor områdene du kan trenge senere, og kontroller det mot hvert annet sted du når over en tunnel. Forvent et kort avbrudd og en lengre hale av glemte enheter: en som fortsatt har den gamle adressen, ser ut til å virke til den trenger gatewayen.

1. Først inventar: ruterens egen adresse, DHCP-området, reserveringer, portvideresendinger og enhver enhet hvis adresse er skrevet inn for hånd.
2. Deretter endrer du ruterens LAN-prefiks og DHCP-området sammen innenfor et vedlikeholdsvindu, og fornyer kablede leases før trådløse.
3. Så retter du de statiske adressene: skrivere, nettverkslagring, alt med en hardkodet gateway.
4. Til slutt kobler du til VPN-klienten igjen og bekrefter at tunneladressen ikke lenger kolliderer med LAN-et.

Gå gjennom adressene i den rekkefølgen i stedet for alle på en gang, og hold det gamle området dokumentert en stund slik at en utdatert enhet er gjenkjennelig i stedet for mystisk. En enhet som aldri fornyer, melder seg ved å ikke nå gatewayen, noe som er et langt bedre spor enn en telefon til support. Hvis ruteren deler ut leases på mer enn et døgn, forkort dem i vinduets varighet.

Hva et alias kan og ikke kan

Når serveren er din, kan oversettelse av adresser på klienten avdekke det eksterne prefikset i et ledig lokalt område, slik at samme vert svarer på en andre adresse. Community-OpenVPN gjør dette med client-nat, og den direktivet er spesifikk for den klienten, fraværende i de kommersielle og mobile klientene folk vanligvis sammenligner den med. Oppsettet krever en rute som samsvarer med oversettelsen, et ledig område for aliaset og en server som er villig til å svare på klientens uoversatte adresse. Ingenting av dette hjelper når klienten tilhører en administrert leverandør du ikke kan konfigurere.

Når endringen er på plass, nå en lokal vert og en ekstern vert først på adresse og deretter på navn, og noter ruten systemet velger hver gang. Et navn kan fortsatt løses til det gamle området, så adresser og navn fortjener uavhengige kontroller. Start én klient og én enhet på serversiden på nytt hvis noen av dem ble stående oppe gjennom endringen, fordi hurtiglagrede nabo-oppføringer lever lenger enn redigeringen.

Skriv ned prefiksene du landet på der folk faktisk ser: nettverksnotatene, ruterens eget kommentarfelt, introduksjonssiden. Noen vil velge 192.168.1.0/24 igjen, og kollisjonen kommer tilbake med dem.