Fjerntilkoblede brukere når ikke det andre stedet gjennom VPN-huben

En fjernbruker kobler til huben, når filserveren på hubens eget LAN, og alt ser friskt ut. Så åpner hun en delt mappe på 10.20.0.50 i hovedkvarteret, som huben når over en separat site-til-site-tunnel, og det går i timeout. Begge tunnelene er oppe, og begge tellerne stiger, så ingen tunnel er ødelagt. Å krysse huben er tre rutervalg på tre enheter, og en tunnel frakter bare de prefiksene den ble bygget for. Her er rekkefølgen jeg sjekker, og kommandoen som viser om hvert steg stemmer.

Transitt krever tre oppslag, ikke én tunnel

Hver enhet gjør sin egen lengste-prefiks-match og glemmer den. Laptopen må sende 10.20.0.50 inn i tunnelene i stedet for til sin lokale ruter. Huben må ta imot en pakke som kom inn på fjernaksess-grensesnittet og gi den videre til site-til-site-grensesnittet. Hovedkvarteret må sende et svar for brukerens adresse tilbake gjennom tunnelen. Feiler bare én av de tre, ser det likt ut i nettleseren: stillhet.

Derfor beviser det så lite å teste hver tunnel alene. Ping mot hubens LAN-adresse øver den første avgjørelsen, og ping mot huben fra hovedkvarteret øver den tredje. Pakken som feiler har brukerpoolen som kilde og det andre stedet som mål, så skriv ned de prefiksene først. Her er poolen 10.80.0.0/24, hubens LAN er 10.10.0.0/24, og hovedkvarteret er 10.20.0.0/24.

Skyv det fjerne prefikset ut til fjernklienten

På en OpenVPN fjernaksess-server lærer klienten ruter ved tilkobling. Uten push sender en klient med delt tunnel 10.20.0.50 til sin egen gateway, og pakken kommer aldri inn i tunnelen.

push "route 10.20.0.0 255.255.255.0"

En pushet rute trer i kraft når klienten kobler til, så en bruker som blir online ser ingenting før hun kobler til på nytt. Kontroller på klienten: ip route get 10.20.0.50 på Linux, route print på Windows. Utdataene skal navngi tunellgrensesnittet.

Push hjelper ikke huben. Det er en melding til klienten, ikke en rute på serveren og ikke en tillatelse til å videresende, så en hub med den perfekte push-linjen slipper likevel flyten én hopp senere. Det er den vanlige grunnen til at folk konkluderer med at pushet feilet.

Gi huben en ekte utgangsrute

Huben trenger sitt eget neste hopp for hovedkvarterets prefiks. På en rutet tunnel er det en vanlig rute gjennom site-til-site-grensesnittet, og én kommando viser både den valgte ruten og den valgte kilden:

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

Når site-til-site-beinet selv er OpenVPN, kan ruten ligge i den konfigurasjonen med peerens tunneladresse som gateway: route 10.20.0.0 255.255.255.0 172.30.0.2. Gatewayen er ikke valgfri. Utelater du den, faller neste hopp tilbake på en implementasjonsstandard, som er forskjellig for en klient med én peer og en hub med flere peers.

Policybasert IPsec er annerledes: hubens kjerne sender pakken til sin vanlige LAN-gateway, og policyen fanger den på vei ut, så en tunnelrute enten gjør ingenting eller leder trafikken forbi policyen. Følg med på kilden i kommandoen ovenfor, fordi 10.10.0.1 i stedet for pooladressen betyr at kjernen valgte en adresse som den fjerne siden vil avvise. iroute er heller ikke svaret; det forteller serveren hvilken klient som eier et subnett bak sin egen tunnel, ikke hvor trafikk for et tredje sted skal sendes.

Utvid den fjerne siden til brukerpoolen

Hovedkvarteret dekker allerede hubens LAN, 10.10.0.0/24. Brukerpoolen er et andre prefiks og må også være med i selektorene, ellers dekker ingen policy et svar adressert til 10.80.0.25. Hver peer navngir det samme paret med prefikssett fra sin egen 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

Den ene enhetens local_ts er den andres remote_ts. Kopierer du hubblokken til hovedkvarteret, blir paret snudd, og child SA kommer aldri opp.

Den eldre ipsec.conf syntaksen bruker en kommaseparert leftsubnet. Den kjørende sikkerhetsassosiasjonen beholder selektorene den forhandlet, så gjenopprett tunnelen etter endringen. En selektor endret klokken 10:00 og testet mot en SA som kom opp klokken 09:40 feiler fortsatt, mens konfigurasjonsfilen ser korrekt ut hele tiden.

Kontroller deretter det siste hoppet. ip route get 10.80.0.25 på det fjerne endepunktet skal peke inn i tunnelen. Hvis tjenesten bruker en LAN-ruter som standard gateway, trenger den ruteren også returruten, ellers dør svaret der. tcpdump -ni eth1 host 10.80.0.25 på det segmentet viser om svaret i det hele tatt forlot endepunktet.

Tillat flyten på huben

Videresending må være aktivert og veien tillatt. Avgrense reglene til de to prefiksene i stedet for å godta alt mellom grensesnittene.

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

Filtrering av returvei er den stille feilen ved siden av: med de to beina på forskjellige grensesnitt kan rp_filter=1 slippe svaret mens telleren til godta-regelen aldri beveger seg. Sammenlign iptables -vnL FORWARD før og etter et forsøk. En regel som aldri øker, nås ikke, så se et lag lenger ned i stedet for å skrive den om.

Hvis bare én gruppe trenger transitt, legg ruten i en fil per klient under client-config-dir i stedet for å utvide det globale pushet. Kilde-NAT på huben fjerner også behovet for en returrute på den fjerne siden, men den skjuler brukerens adresse, så loggene til det fjerne stedet og adressebaserte regler slutter å skille brukere.

Kontroller fra klienten, og rull deretter tilbake i omvendt rekkefølge

Test en TCP-port, ikke bare ICMP, fordi en ping kan gå gjennom mens tjenesten forblir blokkert. nc -vz 10.20.0.50 445 og traceroute -n 10.20.0.50 fra klienten viser om det andre hoppet er hubens tunneladresse. På huben tcpdump -ni tun0 host 10.20.0.50 og det samme filteret på site-til-site-grensesnittet: en forespørsel på begge uten svar på noen av dem flytter problemet til den fjerne siden.

Test deretter noe som må forbli blokkert. Svarer også en vert som poolen aldri skal nå, har du åpnet mer enn transitt og bør snevre inn reglene. En hub som videresender alt til hver spoke, består den første testen og feiler den andre.

Hold en tilbakerullingsliste, fordi fire objekter ble endret og tre er lette å glemme: den pushede ruten, hubens rute, selektorene og brannmurreglene. Angre dem i omvendt rekkefølge, gjenopprett SA-en, og la én bruker koble til på nytt. En delvis tilbakerulling etterlater en rute som peker på en tunnel som ikke lenger passer, noe som er vanskeligere å lese enn den opprinnelige stillheten. OpenVPN 2.6-håndboken dokumenterer push, route og iroute for din versjon.