LAN-ruter pluss VPN-klient: to enheter, to rutetabeller

To enheter videresender pakken, og hver holder sin egen tabell. LAN-ruteren vet at det eksterne prefikset tilhører VPN-klienten, og VPN-klienten vet hvordan den når det prefikset gjennom tunnelen sin. Konfigurer bare den første tabellen, og pakken ankommer en maskin som ikke har noen samsvarende rute, og forlater derfor igjen via standardruten. Det er hele feilen, og fra LAN-siden ser det ut som en rutingsløyfe, fordi det nesten er det.

Tegn de to hoppene før du rører en rute

Ta et illustrativt oppsett: LAN-verter på 192.168.50.0/24, den vanlige ruteren på 192.168.50.1, en dedikert klient på 192.168.50.15 og et eksternt LAN på 10.60.0.0/24 som bare er tilgjengelig gjennom tunnelen den klienten holder. Ingen av de to private områdene overlapper det andre, og tunnelen har sin egen adresseplan.

Begge de private områdene betyr noe, fordi de avgjør hvilken enhet som kan svare. Fjernsiden vil se pakken komme fra klientens tunneladresse, og svaret må finne en vei tilbake til 192.168.50.0/24. Hvis bare den utgående retningen er konfigurert, kan forespørselen virke mens svaret forsvinner.

Trinn 1: rett ruteren mot klienten, ikke mot tunnelen

På LAN-ruteren, legg til en destinasjonsrute der neste hopp 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 posten sier «lever den til maskinen som kan tunnelere». Den sier ingenting om hvordan tunnelen bygges, og den erstatter ikke klientens egen rute. På en administrert ruter ligger ekvivalenten på enhetens side for statiske ruter; på en Linux-ruter hører den til i grensesnittkonfigurasjonen som eier LAN-et, ikke i et skall du lukker.

Sjekk svaret fra den andre kommandoen. Hvis den rapporterer klienten som gateway og LAN-grensesnittet som device, er det første hoppet riktig, og resten av arbeidet er på den andre maskinen.

Trinn 2: gi klienten sin egen rute på tunnelsiden

Klienten mottar nå en pakke for 10.60.0.0/24 og slår opp i sin egen tabell. Hvis tunnelkonfigurasjonen har installert en rute for det prefikset, fortsetter pakken kryptert. Hvis ikke, samsvarer pakken med den vanlige standardruten og går tilbake til 192.168.50.1, som sender den til klienten igjen.

Se før du legger til noe:

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

En manglende prefiksrute i alle tabeller er funnet du leter etter. Legg den til gjennom tunnelens egen konfigurasjon, slik at neste gjenoppkobling installerer den på nytt; en manuell ip route add forsvinner med økten og får feilen tilbake på det minst passende tidspunktet. Neste hopp er tunellgrensesnittet eller adressen VPN-en tildeler som sin peer, avhengig av klienten, og peer-adressen bør komme fra den gjeldende profilen og ikke fra et gammelt notat.

Sløyfen er, når den oppstår, ikke uendelig i praksis: TTL synker ved hver passasje, og pakken dør med en melding om at tiden er overskredet. Derfor kan en gjentatt traceroute antyde en syklus, mens en klient som rett og slett ikke videresender, slipper den samme pakken lydløst.

Trinn 3: tillat videresending og velg returveien

Å motta og å videresende er forskjellige tillatelser. net.ipv4.ip_forward=1 på klienten tillater transit på kjernenivå, og en brannmurregel må fortsatt tillate det mellom LAN-grensesnittet og tunnelen. En regel som tillater tilgang til klientens egen administrasjonsside, tillater ikke transit til det eksterne LAN-et, og forskjellen er lett å overse når samme vert svarer på ping lokalt.

Fjernsiden har speilproblemet. Den må vite at 192.168.50.0/24 er tilgjengelig gjennom denne autentiserte klienten. Med OpenVPN betyr det vanligvis en rute per klient som serverkonfigurasjonen dytter ut, eller en klientspesifikk fil på serveren som erklærer LAN-et bak klienten. Uten det slipper det eksterne LAN-et enten svaret eller sender det til sin egen standardgateway, som er internett.

Kildeoversettelse er alternativet når LAN-prefikset ikke kan annonseres. En avgrenset masquerade-regel på klienten skriver om kilden til tunneladressen, og svar kommer da naturlig tilbake. Den skjuler også hvilken LAN-vert som sendte forespørselen, og den tillater ikke i seg selv fjernsiden å starte tilkoblinger innover. Velg den avveiningen bevisst i stedet for å legge til en generell masquerade og oppdage bivirkningen senere.

Trinn 4: gjør begge beslutningene varige, og test deretter den virkelige veien

Hver rute har en eier, og eieren er konfigurasjonen som gjenopprettes ved oppstart eller ved gjenoppkobling. På ruteren kan det være en statisk ruteoppføring; på klienten kan det være VPN-profilen, NetworkManager eller systemd-networkd. Verifiser ved å koble tunnelen til på nytt og starte klienten på nytt, og les deretter tabellen igjen i stedet for å stole på endringen.

Hold standardruten som bærer tunnelens ytre forbindelse intakt. Å erstatte den for å «forenkle» oppsettet bryter den krypterte veien før noen indre trafikk kan bruke den, og symptomet er en tunnel som aldri gjenopprettes etter endringen.

Test fra en vanlig LAN-vert, ikke fra klienten, fordi en forespørsel som oppstår på klienten aldri utøver ruterens første hopp. Hent en tjeneste som bare finnes på det eksterne LAN-et, og bekreft svarlegemet, og se deretter på klientens tellere eller logger for å se transitten skje. En intern traceroute som viser private hopp beviser videresending, ikke kryptering: den ytre veien er en separat observasjon, og bare tunnelens egne grensesnitttellere viser hva som gikk ut gjennom den.