LAN-rutar og VPN-klient: to einingar, to rutetabellar

To einingar sender pakken vidare, og kvar held sin eigen tabell. LAN-rutaren veit at det eksterne prefikset høyrer til VPN-klienten, og VPN-klienten veit korleis han når det prefikset gjennom tunnelen sin. Set opp berre den første tabellen, og pakken kjem til ei maskin som ikkje har noka samsvarande rute, og forlèt derfor igjen via standardruta. Det er heile feilen, og frå LAN-sida ser det ut som ei rutingsløkke, fordi det nesten er det.

Teikn dei to hoppa før du rører ei rute

Ta eit illustrativt oppsett: LAN-vertar på 192.168.50.0/24, den vanlege rutaren på 192.168.50.1, ein dedikert klient på 192.168.50.15 og eit eksternt LAN på 10.60.0.0/24 som berre er tilgjengeleg gjennom tunnelen den klienten held. Ingen av dei to private områda overlappar det andre, og tunnelen har sin eigen adresseplan.

Begge dei private områda betyr noko, fordi dei avgjer kva eining som kan svare. Fjernsida vil sjå pakken kome frå tunneladressa til klienten, og svaret må finne ein veg tilbake til 192.168.50.0/24. Viss berre den utgåande retninga er sett opp, kan førespurnaden verke medan svaret forsvinn.

Steg 1: rett rutaren mot klienten, ikkje mot tunnelen

På LAN-rutaren, legg til ei destinasjonsrute der neste hopp er LAN-adressa til klienten:

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

Den posten seier «lever han til maskina som kan tunnelere». Han seier ingenting om korleis tunnelen blir bygd, og han erstattar ikkje den eigne ruta til klienten. På ein administrert rutar ligg ekvivalenten på sida til eininga for statiske ruter; på ein Linux-rutar høyrer han til i grensesnittkonfigurasjonen som eig LAN-et, ikkje i eit skal du lukkar.

Sjekk svaret frå den andre kommandoen. Viss han rapporterer klienten som gateway og LAN-grensesnittet som device, er det første hoppet rett, og resten av arbeidet er på den andre maskina.

Steg 2: gi klienten si eiga rute på tunnelsida

Klienten får no ein pakke for 10.60.0.0/24 og slår opp i sin eigen tabell. Viss tunnelkonfigurasjonen hans har installert ei rute for det prefikset, held pakken fram kryptert. Viss ikkje, samsvarer pakken med den vanlege standardruta og går tilbake til 192.168.50.1, som sender han til klienten igjen.

Sjå før du legg til noko:

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

Ei manglande prefiksrute i alle tabellar er funnet du leitar etter. Legg ho til gjennom den eigentlege konfigurasjonen til tunnelen, slik at neste attkopling installerar ho på nytt; ein manuell ip route add forsvinn med økta og får feilen tilbake på det minst passande tidspunktet. Neste hopp er tunellgrensesnittet eller adressa VPN-en tildeler som sin peer, avhengig av klienten, og peer-adressa bør kome frå den gjeldande profilen og ikkje frå eit gammalt notat.

Løkka er, når ho oppstår, ikkje uendeleg i praksis: TTL søkk ved kvar passasje, og pakken døyr med ei melding om at tida er overskriden. Derfor kan ein gjenteken traceroute tyde på ein syklus, medan ein klient som rett og slett ikkje sender vidare, slepp den same pakken lydlaust.

Steg 3: tillat vidaresending og vel returvegen

Å ta imot og å senda vidare er ulike løyve. net.ipv4.ip_forward=1 på klienten tillèt transit på kjernenivå, og ei brannmurregel må framleis tillate det mellom LAN-grensesnittet og tunnelen. Ei regel som tillèt tilgang til den eigne administrasjonssida til klienten, tillèt ikkje transit til det eksterne LAN-et, og skilnaden er lett å oversjå når same vert svarar på ping lokalt.

Fjernsida har spegelproblemet. Ho må vita at 192.168.50.0/24 er tilgjengeleg gjennom denne autentiserte klienten. Med OpenVPN betyr det vanlegvis ei rute per klient som serverkonfigurasjonen dyttar ut, eller ei klientspesifikk fil på serveren som erklærer LAN-et bak klienten. Utan det slepp det eksterne LAN-et anten svaret eller sender det til sin eigen standardgateway, som er internett.

Kjeldeomsetting er alternativet når LAN-prefikset ikkje kan annonserast. Ei avgrensa masquerade-regel på klienten skriv om kjelda til tunneladressa, og svar kjem då naturleg tilbake. Ho løyner òg kva LAN-vert som sende førespurnaden, og ho tillèt ikkje av seg sjølv fjernsida å starte tilkoplingar innover. Vel den avveginga medvite i staden for å leggje til ein generell masquerade og oppdage biverknaden seinare.

Steg 4: gjer båe avgjerdene varige, og test deretter den verkelege vegen

Kvar rute har ein eigar, og eigaren er konfigurasjonen som blir gjenoppretta ved oppstart eller ved attkopling. På rutaren kan det vere ein statisk rutepost; på klienten kan det vere VPN-profilen, NetworkManager eller systemd-networkd. Stadfest ved å kople tunnelen til på nytt og starte klienten på nytt, og les deretter tabellen igjen i staden for å stole på endringa.

Hald standardruta som ber den ytre sambindinga til tunnelen intakt. Å erstatta ho for å «forenkle» oppsettet bryt den krypterte vegen før nokon indre trafikk kan bruke ho, og symptomet er ein tunnel som aldri blir gjenoppretta etter endringa.

Test frå ein vanleg LAN-vert, ikkje frå klienten, fordi ein førespurnad som oppstår på klienten aldri utøver det første hoppet til rutaren. Hent ein teneste som berre finst på det eksterne LAN-et, og stadfest svarlekamen, og sjå deretter på teljarane eller loggane til klienten for å sjå transitten skje. Ein intern traceroute som viser private hopp beviser vidaresending, ikkje kryptering: den ytre vegen er ein separat observasjon, og berre dei eigne grensesnitteljarane til tunnelen viser kva som gjekk ut gjennom han.