Næste hop i en VPN-rute: hvorfor gatewayen skal være lokalt tilgængelig

En rute ind i et VPN-netværk bærer to adresser, som er lette at forveksle: destinationspræfikset, som pakken forsøger at nå, og det næste hop, som flytter den et skridt nærmere. På en LAN-vært skal det næste hop være en router, som du faktisk kan nå på samme link. Den fjerne VPN-adresse er ikke et næste hop, uanset hvor pænt den passer til den destination, du har i tankerne.

Denne kørebog dækker det almindelige tilfælde: en bærbar computer på 192.168.20.0/24, en VPN-gateway med LAN-adresse 192.168.20.5 og et fjernnetværk 10.70.0.0/24 bag den gateway. Alle kommandoer nedenfor forudsætter, at du er på den bærbare computer, medmindre andet er sagt.

To adresser, én rute

Den tilsigtede post er 10.70.0.0/24 via 192.168.20.5. Præfikset siger, hvor pakken skal hen; via-adressen siger, hvem der bærer den derhen. Kernen nægter at installere en rute, hvis gateway den ikke kan nå gennem det interface, du angiver, og den afvisning er hele pointen: et næste hop, der har brug for tunnelen for at være tilgængeligt, kan ikke være det næste hop, der bygger tunnelen.

Så den første kontrol er ikke «er gatewayen oppe», men «er gatewayen på dette link». Den bærbare computers eget subnet, dens ARP- eller naboindgang og interfacet i ruten skal alle stemme overens. En adresse, der kun findes inde i 10.70.0.0/24, kan være destination for en anden rute, aldrig via for den første.

Hvad det næste hop forpligter gatewayen til

Installation af ruten på den bærbare computer afgør kun den første overdragelse. Derefter har gatewayen brug for sin egen vej: videresendelse aktiveret, en tunnelrute for 10.70.0.0/24 og enhver adgangspolitik, der styrer, hvem der må bruge den. På Linux er det net.ipv4.ip_forward=1 plus en tunnelrute; en firewall foran den har brug for en regel, der tillader den videresendte strøm.

Retningen tilbage er den del, folk glemmer. Fjernsiden skal have en rute tilbage til 192.168.20.0/24, eller designet skal oversætte den bærbare computers kilde til noget, fjernsiden kender. En fungerende ping fra gatewayen beviser, at gatewayen kan nå fjernnetværket; den siger intet om, hvorvidt den bærbare computers pakker overlever turen tilbage.

Kontroller opslaget fra den vært, der sender

Spørg kernen, hvilket næste hop den ville vælge, og læs interfacet 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 opslaget rapporterer gatewayen og LAN-interfacet, er det første ben konfigureret som tilsigtet. Hvis det rapporterer tunneleenheden, er noget tidligere i tabellen mere specifikt og vinder. Hvis ruten slet ikke kan installeres, fortæller kernen dig, at gatewayen ikke kan nås, og den besked er mere nyttig end enhver pakkefangst.

Gentag derefter testen fra det rigtige sted. En anmodning, der oprettes på gatewayen, bruger gatewayens egen kildeadresse, hvilket kan skjule en manglende returrute eller en politik, der kun tillader bestemte kilder. ip-route-manualen adskiller destination, gateway og onlink-tilsidesættelsen, og tilsidesættelsen er værd at forstå, før du bruger den.

Brug ikke onlink til at foregive tilgængelighed

onlink fortæller kernen at springe tilgængelighedskontrollen for en gateway over og sende til den alligevel. Det skaber ikke en vej, opløser ikke ARP for en adresse, der ikke er der, og får ikke en fjernrouter til at svare på dit Ethernet-segment. Det er legitimt for gateways, der svarer, men ikke ligger i et tilsluttet subnet, og det er en fælde, når det bruges til at tysse på en fejl, du ikke har forklaret.

Hvis ruten kun installeres med onlink, er det næste spørgsmål, hvorfor gatewayen ikke er, hvor du tror. Et forkert VLAN, en anden adresse på det forkerte interface eller en tastefejl i den sidste oktet giver alle dette, og hver af dem ødelægger også returvejen, når trafikken begynder at flyde.

Punkt-til-punkt-tunneler er ikke Ethernet

En tunneleenhed laver ikke ARP og har ofte ikke noget meningsfuldt subnet af naboer. Dens ruter ser ofte ud som 10.70.0.0/24 dev tun0, uden nogen via overhovedet, fordi peeren er det eneste andet endepunkt. At kopiere en via i LAN-stil ind i den tabel giver en rute, som kernen kan afvise eller, værre, en der peger på en adresse, som peeren aldrig svarer på.

Hold de to modeller adskilt i kørebogen: en LAN-rute har en tilgængelig gateway, en tunnelrute har et interface og en peer. WireGuard, OpenVPN og IPsec viser alle lidt forskellige former, så noter den form, du faktisk brugte, i stedet for at generalisere fra én vært.

Tilføj, bekræft, rul tilbage

Hele ændringen er tre kommandoer og én kontrol, og den bør skrives ned i den rækkefølge:

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

Bekræft vejen, bekræft én destination, og hold derefter sletningslinjen klar, hvis ændringen gør værten utilgængelig på en måde, du ikke forudså. Hvis ruten skal overleve en genstart, skal du lægge den i værtens netværkskonfiguration i stedet for en shell-profil og teste genstarten, før du regner med den. En rute, der kun findes i det shell, der tilføjede den, er en rute, du vil fejlfinde to gange.