Svar fra site-to-site-VPN går ikke gennem tunnelen

Jeg brugte en formiddag på en tunnel, der kom op rent og flyttede trafik i præcis én retning: filialen kunne nå filserveren i hovedkvarteret, og hver forbindelse åbnet fra hovedkvarteret ind i filialen døde ved det første SYN. SA’erne var oppe, tunneltællerne steg, og håndtrykket var aldrig problemet. Svaret blev rutet et sted hen, som tunnelen ikke dækker, og det valg tilhører den fjerne side. En site-to-site-VPN bærer kun de pakker, som en vært afleverer til gatewayen, og hver vært træffer det valg separat, i hver retning, ud fra sin egen routingtabel.

Begge retninger routes hver for sig

IP husker intet om en samtales retning. Hver vært, der sender en pakke, kører sit eget længste-præfiks-opslag, vælger ét næste hop og glemmer beslutningen. Forespørgslen og svaret er to uafhængige pakker, som tilfældigt hører til samme forbindelse, og tunnelen er ét hop, som enhver af dem kan bruge eller lade være. Intet i IKE-udvekslingen lærer den fjerne server, hvordan den når dit subnet; forhandlingen aftaler kun, hvilke præfikser der må krypteres.

Den aftale er den anden port. På strongSwan er trafikselectorerne leftsubnet og rightsubnet, og en pakke, hvis kilde eller destination falder uden for det forhandlede par, bliver ikke krypteret, hvad routingtabellen så siger. Et præfiks, der routes ind i tunnelen, men mangler i selectorerne, er en stille ensrettet fejl: ruten ser rigtig ud, pakken forlader stadig ukrypteret eller droppes, og kun charon-loggen klager.

Den fjerne vært ved intet om din tunnel

Inde i det fjerne LAN er svaret en almindelig pakke adresseret til din klient. Destinationsværten ser ingen IPsec-header og har ingen grund til at foretrække VPN-gatewayen; den slår dit præfiks op, finder intet mere specifikt end sin standardrute og følger den. Hvis standardruten peger på en central firewall, har firewallen enten en rute tilbage i tunnelen eller ikke. Når den ikke har, får du et stille drop, en ICMP unreachable eller et svar, der forlader via det internetvendte interface og dør.

Et andet interface er nok til at bryde dette, selv når en rute findes. En NAS med management-link på et andet VLAN, en server med backup-uplink, en politikregel der sender et kildeområde ind i en anden tabel: enhver af disse kan fange svaret. På Linux viser ip rule show og ip route show table all regler og tabeller, som standardvisningen skjuler.

Læs beslutningen på den maskine, der sender svaret

Spørg kernen, før du ændrer noget, og giv den kildeadressen, fordi kildafhængige regler ændrer svaret.

ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"

Outputtet angiver det udgående interface og det næste hop. Hvis interfacet ikke er det, der vender mod VPN-gatewayen, har du fundet fejlen, og det resterende arbejde er at vælge, hvor ruten hører til. Et ping fra gatewayen beviser lidt her: det svarer med en adresse, den fjerne vært kan placere, ikke din laptops adresse.

På Windows er ækvivalenterne Find-NetRoute -RemoteIPAddress 10.10.5.10 for beslutningen og Get-NetRoute for tabellen. En rute tilføjet med New-NetRoute, som har en højere metrik end standardruten, taber stille, så læs metrikkolonnen, ikke posten. Bekræft derefter med pakker: tcpdump -ni any "host 10.10.5.10 and tcp port 445" på det fjerne LAN-interface viser forespørgslen, og det samme filter på tunnelsiden viser, om der kom et svar tilbage. Forespørgsel synlig uden svar betyder, at svaret blev rutet et andet sted hen eller droppet; et svar på det forkerte interface giver dig synderen, før du rører en rute.

Når serverens gateway ikke er VPN-endepunktet

Mange steder sætter en firewall mellem serverne og koncentratoren. Den firewall videresender svaret, så den skal have en rute for dit klientpræfiks, der peger på VPN-gatewayen, og videresendelsespolitik i begge retninger. Tilstandsfulde enheder gør det værre: forespørgslen krydsede firewallen fra en LAN-vært, den tillod, svaret ankommer nu fra en anden retning, og forbindelsessporingsposten passer ikke længere, så pakken kasseres som ugyldig i stedet for nægtet. Derfor ser politikloggen tom ud, mens trafikken forsvinder.

Gatewayen har sit eget andet filter. Linux’ reverse-path-filtrering dropper pakker, hvis kilde ikke kan nås gennem det interface, de ankom på, og det er præcis formen af en legitim asymmetrisk returvej. strongSwans vejledning om videresendelse kræver net.ipv4.ip_forward og en lempet net.ipv4.conf.all.rp_filter netop af den grund. En streng værdi på 1 på en af gatewayerne bryder stille en korrekt rute, og nstat -az viser dropene, hvis du ved, hvor du skal kigge.

Rut eller oversæt, og verificér derefter i begge retninger

De to reparationer er ikke ens. At tilføje en rute holder klientadressen intakt, så kildbaserede regler, revisionslogs og applikationer, der registrerer den kaldende, bliver ved med at virke; prisen er, at hvert hop, der træffer beslutningen, skal have ruten, hvilket er flere steder at tage fejl. Maskering på den fjerne gateway skrumper returvejen til ét hop, fordi svaret nu er adresseret til gatewayen selv, og skjuler, hvilken klient der gjorde hvad.

iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADE

Vælg det bevidst: når klienterne først fremstår som gatewayens adresse, holder kildbaserede ACL’er op med at skelne dem, og conntrack skal holde mappingen, så svaret skrives tilbage i tunnelen. Hvis selectorerne stadig udelukker klientpræfikset, ændrer NAT intet, fordi forespørgslen aldrig kom ind i tunnelen.

Før du kalder det løst, skal du bekræfte fire ting i rækkefølge: ruten på den vært, der sender svaret, ruten på hvert hop, der videresender det, selectorerne der dækker begge præfikser, og en optagelse, der viser svaret gå ind i tunnelen med den kilde, du forventer. Gentag derefter testen fra det andet sted. Én retning, der passerer, er et halvåbent design, og den anden retning fejler normalt af en anden grund end den, du netop har repareret.