Nästa hopp i en VPN-rutt: varför gatewayen måste vara lokalt nåbar

En rutt in i ett VPN-nät bär två adresser som är lätta att förväxla: destinationsprefixet som paketet försöker nå och nästa hopp som flyttar det ett steg närmare. På en LAN-värd måste nästa hopp vara en router som du faktiskt kan nå på samma länk. Den avlägsna VPN-adressen är inte ett nästa hopp, hur prydligt den än passar den destination du har i tankarna.

Den här körboken täcker det vanliga fallet: en bärbar dator på 192.168.20.0/24, en VPN-gateway med LAN-adress 192.168.20.5 och ett fjärrnät 10.70.0.0/24 bakom den gatewayen. Alla kommandon nedan förutsätter att du är på den bärbara datorn om inget annat sägs.

Två adresser, en rutt

Den avsedda posten är 10.70.0.0/24 via 192.168.20.5. Prefixet säger vart paketet tar vägen; via-adressen säger vem som bär det dit. Kärnan vägrar installera en rutt vars gateway den inte kan nå via det gränssnitt du anger, och den vägran är hela poängen: ett nästa hopp som behöver tunneln för att vara nåbart kan inte vara det nästa hopp som bygger tunneln.

Så den första kontrollen är inte «är gatewayen uppe» utan «är gatewayen på den här länken». Den bärbara datorns eget subnät, dess ARP- eller grannepost och gränssnittet i rutten måste alla stämma. En adress som bara finns inne i 10.70.0.0/24 kan vara destination för en andra rutt, men aldrig via för den första.

Vad nästa hopp förpliktar gatewayen till

Att installera rutten på den bärbara datorn avgör bara den första överlämningen. Därefter behöver gatewayen sin egen väg: vidarebefordran aktiverad, en tunnelrutt för 10.70.0.0/24 och varje åtkomstpolicy som styr vem som får använda den. På Linux är det net.ipv4.ip_forward=1 plus en tunnelrutt; en brandvägg framför behöver en regel som tillåter det vidarebefordrade flödet.

Riktningen tillbaka är den del folk glömmer. Fjärrsidan måste ha en rutt tillbaka till 192.168.20.0/24, eller så måste designen översätta den bärbara datorns källa till något som fjärrsidan känner till. En fungerande ping från gatewayen bevisar att gatewayen når fjärrnätet; den säger ingenting om huruvida den bärbara datorns paket överlever återresan.

Kontrollera uppslaget från värden som skickar

Fråga kärnan vilket nästa hopp den skulle välja och läs gränssnittet i svaret:

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

Om uppslaget rapporterar gatewayen och LAN-gränssnittet är det första avsnittet konfigurerat som avsett. Om det rapporterar tunnelenheten, är något tidigare i tabellen mer specifikt och vinner. Om rutten inte alls kan installeras säger kärnan att gatewayen inte är nåbar, och det meddelandet är mer användbart än någon paketinsamling.

Upprepa sedan testet från rätt plats. En begäran som skapas på gatewayen använder gatewayens egen källadress, vilket kan dölja en saknad returrutt eller en policy som bara tillåter vissa källor. ip-route-handboken skiljer destination, gateway och onlink-överstyrningen åt, och överstyrningen är värd att förstå innan du använder den.

Använd inte onlink för att låtsas nåbarhet

onlink säger åt kärnan att hoppa över nåbarhetskontrollen för en gateway och ändå skicka dit. Det skapar ingen väg, löser ingen ARP för en adress som inte finns och får ingen fjärrrouter att svara på ditt Ethernet-segment. Det är legitimt för gatewayer som svarar men inte ligger i ett anslutet subnät, och det är en fälla när det används för att tysta ett fel du inte har förklarat.

Om rutten bara installeras med onlink är nästa fråga varför gatewayen inte är där du tror. Fel VLAN, en andra adress på fel gränssnitt eller ett skrivfel i sista oktetten ger alla detta, och var och en av dem bryter också returvägen när trafiken börjar flöda.

Punkt-till-punkt-tunnlar är inte Ethernet

En tunnelenhet gör ingen ARP och har ofta inget meningsfullt subnät av grannar. Dess rutter ser ofta ut som 10.70.0.0/24 dev tun0, helt utan via, eftersom peeren är den enda andra ändpunkten. Att kopiera en via i LAN-stil till den tabellen ger en rutt som kärnan kan avvisa eller, värre, en som pekar på en adress som peeren aldrig svarar på.

Håll de två modellerna åtskilda i körboken: en LAN-rutt har en nåbar gateway, en tunnelrutt har ett gränssnitt och en peer. WireGuard, OpenVPN och IPsec visar alla något olika former, så anteckna den form du faktiskt använde i stället för att generalisera från en enda värd.

Lägg till, bekräfta, rulla tillbaka

Hela ändringen är tre kommandon och en kontroll, och den bör skrivas ned i den ordningen:

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äfta vägen, bekräfta en destination och håll sedan raderingsraden redo ifall ändringen gör värden onåbar på ett sätt du inte förutsåg. Om rutten måste överleva en omstart, lägg den i värdens nätverkskonfiguration i stället för i en shell-profil, och testa omstarten innan du litar på den. En rutt som bara finns i det skal som lade till den är en rutt du kommer att felsöka två gånger.