Fjerntilgangsbrukarar når ikkje den andre staden gjennom VPN-huben

Ein fjernbrukar koplar seg til huben, når filserveren på hubens eigen LAN, og alt ser friskt ut. Så opnar han ei deling på 10.20.0.50 på hovudkontoret, som huben når over ein eigen site-til-site-tunnel, og det går ut på tid. Begge tunnelane er oppe og begge teljarane stig, så ingen av tunnelane er øydelagde. Å krysse huben er tre rutingsval på tre einingar, og ein tunnel ber berre prefiksa han vart bygd for. Her er rekkjefølgja eg sjekkar, og kommandoen som viser om kvart steg held.

Transitt krev tre oppslag, ikkje éin tunnel

Kvar eining gjer si eiga lengst-prefiks-matching og gløymer ho. Laptopen må senda 10.20.0.50 inn i tunnelen og ikkje til den lokale rutaren. Huben må ta ein pakke som kom inn på fjernaksesgrensesnittet og gje han vidare til site-til-site-grensesnittet. Hovudkontoret må senda eit svar for brukaren si adresse tilbake gjennom tunnelen. Kva som helst av dei tre som sviktar ser likt ut i nettlesaren: stille.

Det er derfor testing av kvar tunnel åleine beviser så lite. Å pinge hubens LAN-adresse prøver den første avgjerda, og å pinge huben frå hovudkontoret prøver den tredje. Pakken som sviktar har brukarpoolen som kjelde og den andre staden som mål, så skriv ned dei prefiksa først. Her er poolen 10.80.0.0/24, hubens LAN er 10.10.0.0/24 og hovudkontoret er 10.20.0.0/24.

Skyv det fjerne prefikset til fjernklienten

På ein OpenVPN fjernakesserver lærer klienten ruter ved tilkopling. Utan push sender ein klient med delt tunnel 10.20.0.50 til sin eigen gateway, og pakken kjem aldri inn i tunnelen.

push "route 10.20.0.0 255.255.255.0"

Ei skyvd rute trer i kraft når klienten koplar seg til, så ein brukar som blir verande på nett ser ingenting før han koplar seg til på nytt. Sjekk på klienten: ip route get 10.20.0.50 på Linux, route print på Windows. Utdata skal namngje tunellgrensesnittet.

push hjelper ikkje huben. Det er ei melding til klienten, ikkje ei rute på serveren og ikkje løyve til å videresenda, så ein hub med ei perfekt push-linje slepp likevel straumen éin hopp seinare. Det er den vanlege grunnen til at folk konkluderer med at push feila.

Gje huben ei verkeleg utgangsrute

Huben treng si eiga neste hopp for prefikset til hovudkontoret. På ein ruta tunnel er det ei vanleg rute gjennom site-til-site-grensesnittet, og éin kommando viser både den valde ruta og den valde kjelda:

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

Der site-til-site-beinet sjølv er OpenVPN, kan ruta bu i den konfigurasjonen med tunelladressa til motparten som gateway: route 10.20.0.0 255.255.255.0 172.30.0.2. Gatewayen er ikkje valfri. Let du han ut, fell neste hopp til ein standardverdi i implementasjonen, som skil seg mellom ein klient med éin fjern stad og ein hub med fleire motpartar.

Policy-basert IPsec er annleis: kjernen i huben sender pakken til sin vanlege LAN-gateway og policyen fangar han på veg ut, så ei tunellrute gjer anten ingenting eller leier trafikken forbi policyen. Sjå på kjelda i kommandoen ovanfor, fordi 10.10.0.1 i staden for pooladressa tyder at kjernen valde ei adresse som hi sida vil avvise. Ikkje er iroute svaret heller; han fortel serveren kva klient som eig eit subnett bak sin eigen tunnel, ikkje kvar trafikk for ein tredje stad skal sendast.

Utvid hi sida til brukarpoolen

Hovudkontoret dekkjer alt hubens LAN, 10.10.0.0/24. Brukarpoolen er eit andre prefiks og må òg vera i selektorane, elles dekkjer ingen policy eit svar retta til 10.80.0.25. Kvar motpart namngjev det same paret av prefikssett frå si eiga side:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

local_ts på éi eining er remote_ts på den andre. Kopier hubblokka til hovudkontoret og paret blir snudd, så barnet-SA kjem aldri opp.

Den eldre syntaksen i ipsec.conf brukar leftsubnet skild med komma. Den køyrande tryggingsassosiasjonen held på selektorane han forhandla, så set tunnelen opp på nytt etter endringa. Ein selektor som vart endra klokka 10:00 og testa mot ein SA som kom opp klokka 09:40 sviktar framleis, medan konfigurasjonsfila ser rett ut heile tida.

Sjekk så det siste hoppet. ip route get 10.80.0.25 på fjerndelen skal peike inn i tunnelen. Viss tenesta brukar ein LAN-rutar som standard gateway, treng den rutaren òg returruta, elles døyr svaret der. Å køyre tcpdump -ni eth1 host 10.80.0.25 på det segmentet viser om svaret i det heile forlet endepunktet.

Tillat straumen i huben

Videresending må vera slått på og vegen tillaten. Avgrens reglane til dei to prefiksa i staden for å ta imot alt mellom grensesnittan.

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

Omvendt veg-filtrering er den stille feilen ved sida av: når dei to beina ligg på ulike grensesnitt, kan rp_filter=1 sleppe svaret medan teljaren til tillatingsregelen aldri rører seg. Samanlikn iptables -vnL FORWARD før og etter eit forsøk. Ein regel som aldri aukar blir ikkje nådd, så sjå eit lag lenger ned i staden for å skrive han om.

Viss berre éi gruppe treng transitt, legg ruta i ei fil per klient under client-config-dir i staden for å utvide den globale push-en. Kjelde-NAT i huben fjernar òg trongen for ei returrute på hi sida, men han gøymer brukaradressa, så loggane på den fjerne staden og adressebaserte reglar sluttar å skilje brukarar.

Stadfest frå klienten, og rull så tilbake i motsett rekkjefølgje

Test ein TCP-port, ikkje berre ICMP, fordi ein ping kan gå gjennom medan tenesta blir verande blokkert. nc -vz 10.20.0.50 445 og traceroute -n 10.20.0.50 frå klienten viser om det andre hoppet er tunelladressa til huben. I huben, tcpdump -ni tun0 host 10.20.0.50 og same filter på site-til-site-grensesnittet: ei førespurnad på begge utan svar på nokon av dei flyttar problemet til hi sida.

Test så noko som må bli verande blokkert. Viss ein vert som poolen aldri skal nå òg svarar, opna du meir enn transitt og bør snevre inn reglane. Ein hub som videresender alt til kvar eike går gjennom den første testen og sviktar den andre.

Hald ei tilbakerullingsliste, fordi fire objekt vart endra og tre er lette å gløyme: den skyvde ruta, ruta til huben, selektorane og brannmurreglane. Angre dei i motsett rekkjefølgje, set SA-en opp på nytt og lat éin brukar kople seg til på nytt. Ei delvis tilbakerulling lèt att ei rute som peikar på ein tunnel som ikkje lenger passar, og det er vanskelegare å lese enn den opphavlege stilla. OpenVPN 2.6-handboka dokumenterer push, route og iroute for versjonen din.