LAN-router plus VPN-klient: to enheder, to rutetabeller

To enheder videresender pakken, og hver især holder sin egen tabel. LAN-routeren ved, at det fjernede præfiks tilhører VPN-klienten, og VPN-klienten ved, hvordan det præfiks nås gennem sin tunnel. Konfigurer kun den første tabel, og pakken ankommer til en maskine uden en matchende rute, så den forlader igen via standardruten. Det er hele fejlen, og fra LAN-siden ligner det en routing-loop, fordi det næsten er en.

Tegn de to hop, før du rører en rute

Tag et illustrativt layout: LAN-værter på 192.168.50.0/24, den almindelige router på 192.168.50.1, en dedikeret klient på 192.168.50.15 og et fjern-LAN på 10.60.0.0/24, som kun kan nås gennem den tunnel, klienten holder. Ingen af de private områder overlapper hinanden, og tunnelen har sin egen adresseplan.

Begge private områder betyder noget, fordi de afgør, hvilken enhed der kan svare. Fjernsiden vil se pakken ankomme fra klientens tunneladresse, og dens svar skal finde en vej tilbage til 192.168.50.0/24. Hvis kun den udgående retning er konfigureret, kan anmodningen virke, mens svaret forsvinder.

Trin 1: peg routeren mod klienten, ikke mod tunnelen

Tilføj på LAN-routeren en destinationsrute, hvis næste hop er klientens LAN-adresse:

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

Den post siger “lever den til maskinen, der kan tunnelere”. Den siger intet om, hvordan tunnelen bygges, og den erstatter ikke klientens egen rute. På en administreret router ligger ækvivalenten på enhedens side for statiske ruter; på en Linux-router hører den til i den interfacekonfiguration, der ejer LAN’et, ikke i et shell, du lukker.

Tjek den anden kommandos svar. Hvis den rapporterer klienten som gateway og LAN-interfacet som device, er det første hop korrekt, og det resterende arbejde er på den anden maskine.

Trin 2: giv klienten sin egen rute på tunnelsiden

Klienten modtager nu en pakke til 10.60.0.0/24 og slår op i sin egen tabel. Hvis dens tunnelkonfiguration har installeret en rute til det præfiks, fortsætter pakken krypteret. Hvis ikke, matcher pakken standardruten og går tilbage til 192.168.50.1, som sender den til klienten igen.

Se, før du tilføjer noget:

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

En manglende præfiksrute i alle tabeller er det fund, du leder efter. Tilføj den gennem tunnelens egen konfiguration, så den næste genopkobling installerer den igen; en manuel ip route add forsvinder med sessionen og får fejlen til at vende tilbage på det mest ubelejlige tidspunkt. Næste hop er tunnelinterfacet eller den adresse, VPN’en tildeler som sin peer, afhængigt af klienten, og peer-adressen bør komme fra den aktuelle profil i stedet for en gammel note.

Løkken er, når den opstår, ikke uendelig i praksis: TTL falder ved hver passage, og pakken dør med en time-exceeded-besked. Derfor kan en gentagen traceroute antyde en cyklus, mens en klient, der blot ikke videresender, dropper den samme pakke lydløst.

Trin 3: tillad videresendelse, og vælg returvejen

Modtagelse og videresendelse er forskellige tilladelser. net.ipv4.ip_forward=1 på klienten tillader transit på kernelniveau, og en firewallregel skal stadig tillade det mellem LAN-interfacet og tunnelen. En regel, der tillader adgang til klientens egen administrationsside, tillader ikke transit til fjern-LAN’et, og forskellen er let at overse, når den samme vært svarer på ping lokalt.

Fjernsiden har spejlproblemet. Den skal vide, at 192.168.50.0/24 kan nås gennem denne autentificerede klient. Med OpenVPN betyder det normalt en rute pr. klient, som serverkonfigurationen skubber ud, eller en klientspecifik fil på serveren, der erklærer LAN’et bag klienten. Uden det dropper fjern-LAN’et enten svaret eller sender det til sin egen standardgateway, som er internettet.

Kildeoversættelse er alternativet, når LAN-præfikset ikke kan annonceres. En afgrænset masquerade-regel på klienten omskriver kilden til tunneladressen, og svar vender så naturligt tilbage. Den skjuler også, hvilken LAN-vært der kom med anmodningen, og den tillader ikke i sig selv fjernsiden at starte forbindelser indad. Vælg den afvejning bevidst i stedet for at tilføje en blanket masquerade og opdage bivirkningen senere.

Trin 4: gør begge beslutninger varige, og test så den rigtige vej

Hver rute har en ejer, og ejeren er den konfiguration, der gendannes ved opstart eller ved genopkobling. På routeren kan det være en statisk ruteindgang; på klienten kan det være VPN-profilen, NetworkManager eller systemd-networkd. Bekræft ved at genopkoble tunnelen og genstarte klienten, og læs derefter tabellen igen i stedet for at stole på ændringen.

Hold standardruten, der bærer tunnelens ydre forbindelse, intakt. At erstatte den for at “forenkle” opsætningen bryder den krypterede vej, før nogen indre trafik kan bruge den, og symptomet er en tunnel, der aldrig genetableres efter ændringen.

Test fra en almindelig LAN-vært, ikke fra klienten, fordi en anmodning, der opstår på klienten, aldrig udøver routerens første hop. Hent en tjeneste, der kun findes på fjern-LAN’et, og bekræft svarlegemet, og tjek derefter klientens tællere eller logfiler for at se transit’en ske. En indre traceroute, der viser private hop, beviser videresendelse, ikke kryptering: den ydre vej er en separat observation, og kun tunnelens egne interfacetællere viser, hvad der forlod gennem den.