Neste hopp i ei VPN-rute: kvifor gatewayen må vere lokalt tilgjengeleg

Ei rute inn i eit VPN-nettverk ber to adresser som er lette å forveksle: destinasjonsprefikset pakken prøver å nå, og neste hopp som flyttar han eitt steg nærare. På ein LAN-vert må det neste hoppet vere ein ruter du faktisk kan nå på same lenkja. Den eksterne VPN-adressa er ikkje eit neste hopp, uansett kor pent ho passar til destinasjonen du har i tankane.

Denne køyreboka dekkjer det vanlege tilfellet: ein berbar datamaskin på 192.168.20.0/24, ein VPN-gateway med LAN-adresse 192.168.20.5 og eit eksternt nettverk 10.70.0.0/24 bak den gatewayen. Alle kommandoane nedanfor føreset at du er på den berbare datamaskina med mindre anna er sagt.

To adresser, éi rute

Den tiltenkte oppføringa er 10.70.0.0/24 via 192.168.20.5. Prefikset seier kvar pakken skal, og via-adressa seier kven som ber han dit. Kjernen nektar å installere ei rute der han ikkje kan nå gatewayen gjennom grensesnittet du oppgir, og den nektinga er heile poenget: eit neste hopp som treng tunnelen for å vere tilgjengeleg, kan ikkje vere det neste hoppet som byggjer tunnelen.

Så den første kontrollen er ikkje «er gatewayen oppe», men «er gatewayen på denne lenkja». Det berbare datamaskina sitt eige subnett, hennar ARP- eller nabo-oppføring og grensesnittet i ruta må alle stemme. Ei adresse som berre finst inne i 10.70.0.0/24 kan vere destinasjonen for ei anna rute, men aldri via for den første.

Kva neste hopp forpliktar gatewayen til

Å installere ruta på den berbare datamaskina avgjer berre den første overleveringa. Deretter treng gatewayen sin eigen veg: vidaresending aktivert, ei tunnelrute for 10.70.0.0/24 og kvar tilgangspolicy som styrer kven som kan bruke ho. På Linux er det net.ipv4.ip_forward=1 pluss ei tunnelrute; ein brannmur framfor treng ein regel som lèt den vidaresende straumen gjennom.

Retninga tilbake er den delen folk gløymer. Den eksterne sida må ha ei rute tilbake til 192.168.20.0/24, eller designet må omsetje kjelda til den berbare datamaskina til noko den eksterne sida kjenner. Ein fungerande ping frå gatewayen beviser at gatewayen når det eksterne nettverket; han seier ingenting om korvidt pakkane frå den berbare datamaskina overlever turen tilbake.

Kontroller oppslaget frå verten som sender

Spør kjernen kva neste hopp han ville velje, 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

Viss oppslaget rapporterer gatewayen og LAN-grensesnittet, er den første etappen konfigurert som tiltenkt. Viss det rapporterer tunnel-eininga, er noko tidlegare i tabellen meir spesifikt og vinn. Viss ruta ikkje let seg installere i det heile, fortel kjernen deg at gatewayen ikkje er tilgjengeleg, og den meldinga er meir nyttig enn kva pakkefangst som helst.

Gjenta deretter testen frå rett stad. Ein førespurnad som vert oppretta på gatewayen, brukar gatewayen si eiga kjeldeadresse, noko som kan skjule ei manglande returrute eller ein policy som berre lèt bestemte kjelder gjennom. ip-route-handboka skil destinasjon, gateway og onlink-overstyringa, og overstyringa er verd å forstå før du brukar ho.

Ikkje bruk onlink for å late som tilgjengelegheit

onlink ber kjernen hoppe over tilgjengelegheitssjekken for ein gateway og sende dit likevel. Det lagar ikkje ein veg, løyser ikkje ARP for ei adresse som ikkje er der, og får ikkje ein ekstern ruter til å svare på Ethernet-segmentet ditt. Det er legitimt for gatewayar som svarar, men ikkje ligg i eit tilkopla subnett, og det er ei felle når det vert brukt til å dempe ein feil du ikkje har forklart.

Viss ruta berre vert installert med onlink, er det neste spørsmålet kvifor gatewayen ikkje er der du trur. Feil VLAN, ei anna adresse på feil grensesnitt eller ein skrivefeil i siste oktett gjev alle dette, og kvar av dei bryt også returvegen når trafikken byrjar å flyte.

Punkt-til-punkt-tunnelar er ikkje Ethernet

Ei tunnel-eining gjer ikkje ARP og har ofte ikkje noko meiningsfullt subnett av naboar. Rutene hennar ser ofte ut som 10.70.0.0/24 dev tun0, heilt utan via, fordi peeren er det einaste andre endepunktet. Å kopiere ein via i LAN-stil inn i den tabellen gjev ei rute som kjernen kan avvise, eller, verre, ei som peikar på ei adresse peeren aldri svarar på.

Hald dei to modellane skilde i køyreboka: ei LAN-rute har ein tilgjengeleg gateway, ei tunnelrute har eit grensesnitt og ein peer. WireGuard, OpenVPN og IPsec viser alle litt ulike former, så noter forma du faktisk brukte i staden for å generalisere frå éin vert.

Legg til, stadfest, rull tilbake

Heile endringa er tre kommandoar og éin kontroll, og ho bør skrivast ned i den rekkjefølgja:

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

Stadfest vegen, stadfest éin destinasjon, og hald deretter slette-linja klar i tilfelle endringa gjer verten utilgjengeleg på ein måte du ikkje forutsåg. Viss ruta må overleve ein omstart, legg ho i nettverkskonfigurasjonen til verten i staden for i ein shell-profil, og test omstarten før du stolar på ho. Ei rute som berre finst i skalet som la ho til, er ei rute du vil feilsøke to gonger.