Neste hopp i en VPN-rute: hvorfor gatewayen må være lokalt tilgjengelig

En rute inn i et VPN-nettverk bærer to adresser som er lette å forveksle: destinasjonsprefikset pakken prøver å nå, og neste hopp som flytter den ett skritt nærmere. På en LAN-vert må det neste hoppet være en ruter du faktisk kan nå på samme lenke. Den eksterne VPN-adressen er ikke et neste hopp, uansett hvor pent den passer til destinasjonen du har i tankene.

Denne kjøreboken dekker det vanlige tilfellet: en bærbar datamaskin på 192.168.20.0/24, en VPN-gateway med LAN-adresse 192.168.20.5 og et eksternt nettverk 10.70.0.0/24 bak den gatewayen. Alle kommandoene nedenfor forutsetter at du er på den bærbare datamaskinen med mindre annet er sagt.

To adresser, én rute

Den tiltenkte oppføringen er 10.70.0.0/24 via 192.168.20.5. Prefikset sier hvor pakken skal, og via-adressen sier hvem som bærer den dit. Kjernen nekter å installere en rute der den ikke kan nå gatewayen gjennom grensesnittet du oppgir, og den nektelsen er hele poenget: et neste hopp som trenger tunnelen for å være tilgjengelig, kan ikke være det neste hoppet som bygger tunnelen.

Så den første kontrollen er ikke «er gatewayen oppe», men «er gatewayen på denne lenken». Den bærbare datamaskinens eget subnett, dens ARP- eller nabo-oppføring og grensesnittet i ruten må alle stemme. En adresse som bare finnes inne i 10.70.0.0/24 kan være destinasjonen for en annen rute, men aldri via for den første.

Hva neste hopp forplikter gatewayen til

Å installere ruten på den bærbare datamaskinen avgjør bare den første overleveringen. Deretter trenger gatewayen sin egen vei: videresending aktivert, en tunnelrute for 10.70.0.0/24 og enhver tilgangspolicy som styrer hvem som kan bruke den. På Linux er det net.ipv4.ip_forward=1 pluss en tunnelrute; en brannmur foran trenger en regel som tillater den videresendte strømmen.

Retningen tilbake er den delen folk glemmer. Den eksterne siden må ha en rute tilbake til 192.168.20.0/24, eller designet må oversette kilden til den bærbare datamaskinen til noe den eksterne siden kjenner. En fungerende ping fra gatewayen beviser at gatewayen når det eksterne nettverket; den sier ingenting om hvorvidt pakkene fra den bærbare datamaskinen overlever turen tilbake.

Kontroller oppslaget fra verten som sender

Spør kjernen hvilket neste hopp den ville velge, og les grensesnittet i svaret:

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

Hvis oppslaget rapporterer gatewayen og LAN-grensesnittet, er den første etappen konfigurert som tiltenkt. Hvis det rapporterer tunnel-enheten, er noe tidligere i tabellen mer spesifikt og vinner. Hvis ruten ikke lar seg installere i det hele tatt, forteller kjernen deg at gatewayen ikke er tilgjengelig, og den meldingen er mer nyttig enn enhver pakkefangst.

Gjenta deretter testen fra riktig sted. En forespørsel som opprettes på gatewayen, bruker gatewayens egen kildeadresse, noe som kan skjule en manglende returrute eller en policy som bare tillater bestemte kilder. ip-route-håndboken skiller destinasjon, gateway og onlink-overstyringen, og overstyringen er verdt å forstå før du bruker den.

Ikke bruk onlink for å late som tilgjengelighet

onlink ber kjernen hoppe over tilgjengelighetssjekken for en gateway og sende dit likevel. Det lager ikke en vei, løser ikke ARP for en adresse som ikke er der, og får ikke en ekstern ruter til å svare på Ethernet-segmentet ditt. Det er legitimt for gatewayer som svarer, men ikke ligger i et tilkoblet subnett, og det er en felle når det brukes til å dempe en feil du ikke har forklart.

Hvis ruten bare installeres med onlink, er det neste spørsmålet hvorfor gatewayen ikke er der du tror. Feil VLAN, en annen adresse på feil grensesnitt eller en skrivefeil i siste oktett gir alle dette, og hver av dem bryter også returveien når trafikken begynner å flyte.

Punkt-til-punkt-tunneler er ikke Ethernet

En tunnel-enhet gjør ikke ARP og har ofte ikke noe meningsfullt subnett av naboer. Rutene dens ser ofte ut som 10.70.0.0/24 dev tun0, helt uten via, fordi peeren er det eneste andre endepunktet. Å kopiere en via i LAN-stil inn i den tabellen gir en rute som kjernen kan avvise, eller, verre, en som peker på en adresse peeren aldri svarer på.

Hold de to modellene adskilt i kjøreboken: en LAN-rute har en tilgjengelig gateway, en tunnelrute har et grensesnitt og en peer. WireGuard, OpenVPN og IPsec viser alle litt forskjellige former, så noter formen du faktisk brukte i stedet for å generalisere fra én vert.

Legg til, bekreft, rull tilbake

Hele endringen er tre kommandoer og én kontroll, og den bør skrives ned i den rekkefølgen:

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

Bekreft veien, bekreft én destinasjon, og hold deretter slette-linjen klar i tilfelle endringen gjør verten utilgjengelig på en måte du ikke forutså. Hvis ruten må overleve en omstart, legg den i vertens nettverkskonfigurasjon i stedet for i en shell-profil, og test omstarten før du stoler på den. En rute som bare finnes i skallet som la den til, er en rute du vil feilsøke to ganger.