Fjernebrugere kan ikke nå det andet site gennem VPN-hubben

En fjernbruger forbinder til hubben, når filserveren på hubbens eget LAN, og alt ser sundt ud. Så åbner brugeren en delt mappe på 10.20.0.50 i hovedkvarteret, som hubben når over en separat site-til-site-tunnel, og det timer ud. Begge tunneler er oppe, og begge tællere stiger, så ingen tunnel er i stykker. At krydse hubben er tre routingbeslutninger på tre enheder, og en tunnel bærer kun de præfikser, den blev bygget til. Her er den rækkefølge, jeg kontrollerer, og den kommando, der viser, om hvert skridt holder.

Transit kræver tre opslag, ikke én tunnel

Hver enhed laver sit eget længste-præfiks-match og glemmer det. Laptoppen skal sende 10.20.0.50 ind i tunnelen i stedet for til sin lokale router. Hubben skal tage en pakke, der ankom på fjernadgangsinterfacet, og give den videre til site-til-site-interfacet. Hovedkvarteret skal sende et svar til brugerens adresse tilbage gennem tunnelen. Fejler blot én af de tre, ser det ens ud i browseren: tavshed.

Derfor beviser det så lidt at teste hver tunnel alene. Ping til hubbens LAN-adresse øver den første beslutning, og ping til hubben fra hovedkvarteret øver den tredje. Den pakke, der fejler, har brugerpuljen som kilde og det andet site som destination, så skriv de præfikser ned først. Her er puljen 10.80.0.0/24, hubbens LAN er 10.10.0.0/24, og hovedkvarteret er 10.20.0.0/24.

Skub det fjerne præfiks ud til fjernklienten

På en OpenVPN fjernadgangsserver lærer klienten ruter ved forbindelse. Uden et push sender en split-tunnel-klient 10.20.0.50 til sin egen gateway, og pakken kommer aldrig ind i tunnelen.

push "route 10.20.0.0 255.255.255.0"

En pushet rute slår igennem, når klienten forbinder, så en bruger, der forbliver online, ser intet, før vedkommende genopretter forbindelsen. Kontroller på klienten: ip route get 10.20.0.50 på Linux, route print på Windows. Outputtet skal navngive tunnelinterfacet.

Push hjælper ikke hubben. Det er en besked til klienten, ikke en rute på serveren og ikke en tilladelse til at videresende, så en hub med den perfekte push-linje taber stadig flowet et hop senere. Det er den sædvanlige grund til, at folk konkluderer, at pushet fejlede.

Giv hubben en rigtig udgangsrute

Hubben har brug for sit eget næste hop til hovedkvarterets præfiks. På en routet tunnel er det en almindelig rute gennem site-til-site-interfacet, og én kommando viser både den valgte rute og den valgte kilde:

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-benet selv er OpenVPN, kan ruten ligge i den konfiguration med peerens tunneladresse som gateway: route 10.20.0.0 255.255.255.0 172.30.0.2. Gatewayen er ikke valgfri. Udelader du den, falder næste hop tilbage på en implementeringsstandard, som er forskellig for en enkelt-peer-klient og en hub med flere peers.

Politikbaseret IPsec er anderledes: hubbens kernel sender pakken til sin normale LAN-gateway, og politikken fanger den på vej ud, så en tunnelrute enten intet gør eller leder trafik forbi politikken. Hold øje med kilden i kommandoen ovenfor, fordi 10.10.0.1 i stedet for puljeadressen betyder, at kernen valgte en adresse, som den fjerne side vil afvise. iroute er heller ikke svaret; det fortæller serveren, hvilken klient der ejer et undernet bag sin egen tunnel, ikke hvor trafik til et tredje site skal sendes hen.

Udvid den fjerne side til brugerpuljen

Hovedkvarteret dækker allerede hubbens LAN, 10.10.0.0/24. Brugerpuljen er et andet præfiks og skal også med i selectors, ellers dækker ingen politik et svar adresseret til 10.80.0.25. Hver peer angiver det samme par præfikssæt 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 enheds local_ts er den andens remote_ts. Kopierer du hubbens blok til hovedkvarteret, er parret omvendt, og child SA kommer aldrig op.

Den ældre ipsec.conf syntaks bruger et kommaadskilt leftsubnet. Den kørende sikkerhedsassociation beholder de selectors, den forhandlede, så genopret tunnelen efter ændringen. Et selector ændret klokken 10:00 og testet mod en SA, der kom op klokken 09:40, fejler stadig, mens konfigurationsfilen ser korrekt ud hele tiden.

Kontroller derefter det sidste hop. ip route get 10.80.0.25 på det fjerne endepunkt skal pege ind i tunnelen. Hvis tjenesten bruger en LAN-router som standardgateway, har den router også brug for returruten, ellers dør svaret der. At køre tcpdump -ni eth1 host 10.80.0.25 på det segment viser, om svaret overhovedet forlod endepunktet.

Tillad flowet på hubben

Videresendelse skal være aktiveret, og stien tilladt. Afgræns reglerne til de to præfikser i stedet for at acceptere alt mellem interfacene.

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 af returvej er den stille fejl ved siden af: med de to ben på forskellige interfaces kan rp_filter=1 tabe svaret, mens acceptreglens tæller aldrig flytter sig. Sammenlign iptables -vnL FORWARD før og efter et forsøg. En regel, der aldrig tæller op, nås ikke, så kig et lag længere ned i stedet for at skrive den om.

Hvis kun én gruppe har brug for transit, så læg ruten i en fil for hver klient under client-config-dir i stedet for at udvide det globale push. Kilde-NAT på hubben fjerner også behovet for en returrute på den fjerne side, men det skjuler brugerens adresse, så det fjerne sites logfiler og adressebaserede regler holder op med at skelne brugere.

Kontroller fra klienten, og rul derefter tilbage i omvendt rækkefølge

Test en TCP-port, ikke kun ICMP, fordi et ping kan gå igennem, mens tjenesten forbliver blokeret. nc -vz 10.20.0.50 445 og traceroute -n 10.20.0.50 fra klienten viser, om det andet hop er hubbens tunneladresse. På hubben tcpdump -ni tun0 host 10.20.0.50 og det samme filter på site-til-site-interfacet: en anmodning på begge uden svar på nogen af dem flytter problemet til den fjerne side.

Test derefter noget, der skal forblive blokeret. Hvis en vært, som puljen aldrig bør nå, også svarer, har du åbnet mere end transit og bør indsnævre reglerne. En hub, der videresender alt til alle spokes, består den første test og fejler den anden.

Hold en tilbagerulningsliste, fordi fire objekter blev ændret, og tre er nemme at glemme: den pushede rute, hubbens rute, selectors og firewallreglerne. Fortryd dem i omvendt rækkefølge, genopret SA’en, og lad én bruger genoprette forbindelsen. En delvis tilbagerulning efterlader en rute, der peger på en tunnel, som ikke længere passer, hvilket er sværere at læse end den oprindelige tavshed. OpenVPN 2.6-manualen dokumenterer push, route og iroute for din version.