LAN-router plus VPN-klient: två enheter, två routingtabeller

Två enheter vidarebefordrar paketet och var och en håller sin egen tabell. LAN-routern vet att det avlägsna prefixet tillhör VPN-klienten, och VPN-klienten vet hur den når prefixet genom sin tunnel. Konfigurera bara den första tabellen och paketet anländer till en maskin utan matchande väg, så det lämnar igen via standardvägen. Det är hela felet, och från LAN-sidan ser det ut som en routingloop, eftersom det nästan är en.

Rita de två hoppen innan du rör en väg

Ta en illustrativ uppställning: LAN-värdar på 192.168.50.0/24, den vanliga routern på 192.168.50.1, en dedikerad klient på 192.168.50.15 och ett avlägset LAN på 10.60.0.0/24 som bara nås genom tunneln som den klienten håller. Inget av de två privata områdena överlappar det andra, och tunneln har sin egen adressplan.

Båda privata områdena spelar roll eftersom de avgör vilken enhet som kan svara. Fjärrsidan ser paketet komma från klientens tunneladress, och svaret måste hitta en väg tillbaka till 192.168.50.0/24. Om bara den utgående riktningen är konfigurerad kan förfrågan fungera medan svaret försvinner.

Steg 1: rikta routern mot klienten, inte mot tunneln

På LAN-routern, lägg till en destinationsväg vars nästa hopp är klientens LAN-adress:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Den posten säger ”leverera det till maskinen som kan tunnla”. Den säger inget om hur tunneln byggs, och den ersätter inte klientens egen väg. På en hanterad router bor motsvarigheten på enhetens sida för statiska rutter; på en Linux-router hör den till gränssnittskonfigurationen som äger LAN:et, inte till ett skal du stänger.

Kontrollera svaret från det andra kommandot. Om det rapporterar klienten som gateway och LAN-gränssnittet som device är det första hoppet korrekt, och resten av arbetet ligger på den andra maskinen.

Steg 2: ge klienten en egen väg på tunnelsidan

Klienten tar nu emot ett paket för 10.60.0.0/24 och tittar i sin egen tabell. Om dess tunnelkonfiguration har installerat en väg för prefixet fortsätter paketet krypterat. Om inte matchar paketet standardvägen och går tillbaka till 192.168.50.1, som skickar det till klienten igen.

Titta innan du lägger till något:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

En saknad prefixväg i alla tabeller är det fynd du letar efter. Lägg till den via tunnelns egen konfiguration, så att nästa återanslutning installerar den igen; en manuell ip route add försvinner med sessionen och får felet att komma tillbaka vid minst lämplig tidpunkt. Nästa hopp är tunnelgränssnittet eller adressen som VPN:en tilldelar som sin peer, beroende på klienten, och peer-adressen bör komma från den aktuella profilen och inte från en gammal anteckning.

Loopen är, när den inträffar, inte oändlig i praktiken: TTL sjunker vid varje passage och paketet dör med ett time-exceeded-meddelande. Därför kan en upprepad traceroute antyda en cykel, medan en klient som helt enkelt inte vidarebefordrar tappar samma paket tyst.

Steg 3: tillåt vidarebefordran och välj returvägen

Att ta emot och att vidarebefordra är olika behörigheter. net.ipv4.ip_forward=1 på klienten tillåter transit på kärnnivå, och en brandväggsregel måste fortfarande tillåta det mellan LAN-gränssnittet och tunneln. En regel som tillåter åtkomst till klientens egen administrationssida tillåter inte transit till det avlägsna LAN:et, och skillnaden är lätt att missa när samma värd svarar på ping lokalt.

Fjärrsidan har spegelproblemet. Den måste veta att 192.168.50.0/24 är nåbar genom denna autentiserade klient. Med OpenVPN betyder det vanligtvis en väg per klient som serverkonfigurationen skjuter ut, eller en klientspecifik fil på servern som deklarerar LAN:et bakom klienten. Utan det tappar fjärr-LAN:et antingen svaret eller skickar det till sin egen standardgateway, det vill säga internet.

Källöversättning är alternativet när LAN-prefixet inte kan annonseras. En avgränsad masquerade-regel på klienten skriver om källan till tunneladressen, och svar kommer då tillbaka naturligt. Den döljer också vilken LAN-värd som gjorde förfrågan, och den tillåter inte i sig själv fjärrsidan att starta anslutningar inåt. Välj den avvägningen medvetet i stället för att lägga till en allmän masquerade och upptäcka bieffekten senare.

Steg 4: gör båda besluten varaktiga och testa sedan den verkliga vägen

Varje väg har en ägare, och ägaren är konfigurationen som återskapas vid start eller vid återanslutning. På routern kan det vara en statisk vägpost; på klienten kan det vara VPN-profilen, NetworkManager eller systemd-networkd. Verifiera genom att återansluta tunneln och starta om klienten, och läs sedan tabellen igen i stället för att lita på ändringen.

Håll standardvägen som bär tunnelns yttre förbindelse intakt. Att ersätta den för att ”förenkla” uppsättningen bryter den krypterade vägen innan någon inre trafik kan använda den, och symtomet är en tunnel som aldrig återupprättas efter ändringen.

Testa från en vanlig LAN-värd, inte från klienten, eftersom en förfrågan som uppstår på klienten aldrig utnyttjar routerns första hopp. Hämta en tjänst som bara finns på det avlägsna LAN:et och bekräfta svarskroppen, och titta sedan på klientens räknare eller loggar för att se transit ske. En intern traceroute som visar privata hopp bevisar vidarebefordran, inte kryptering: den yttre vägen är en separat observation, och bara tunnelns egna gränssnittsräknare visar vad som gick ut genom den.