Antwoord van site-naar-site-VPN gaat niet door de tunnel
Een antwoord dat de tunnel overslaat, is een routeringsbeslissing aan de andere kant. Controleer de hosttabel, de selectors en rp_filter, en kies dan route of NAT.
Ik bracht een ochtend door aan een tunnel die schoon omhoogkwam en verkeer in precies één richting verplaatste: de vestiging kon de fileserver op het hoofdkantoor bereiken, en elke verbinding die vanaf het hoofdkantoor naar de vestiging werd geopend, stierf bij de eerste SYN. De SA’s stonden, de tunneltellers liepen op, en de handshake was nooit het probleem. Het antwoord werd gerouteerd naar een plek die de tunnel niet dekt, en die keuze is aan de andere kant. Een site-naar-site-VPN vervoert alleen de pakketten die een host aan de gateway geeft, en elke host maakt die keuze apart, in elke richting, vanuit zijn eigen routingtabel.
Beide richtingen worden apart gerouteerd
IP bewaart niets over de richting van een gesprek. Elke host die een pakket verstuurt, doet zijn eigen zoekactie naar de langste prefix, kiest één volgende hop en vergeet de beslissing. Het verzoek en het antwoord zijn twee losse pakketten die toevallig bij dezelfde verbinding horen, en de tunnel is één hop die elk van beide kan gebruiken of niet. Niets in de IKE-uitwisseling leert de externe server hoe hij uw subnet bereikt; de onderhandeling spreekt alleen af welke prefixen versleuteld mogen worden.
Die afspraak is de tweede poort. Bij strongSwan zijn de traffic selectors leftsubnet en rightsubnet, en een pakket waarvan de bron of bestemming buiten het onderhandelde paar valt, wordt niet versleuteld, wat de routingtabel ook zegt. Een prefix dat de tunnel in wordt gerouteerd maar in de selectors ontbreekt, is een stille eenrichtingsfout: de route ziet er goed uit, het pakket gaat alsnog onversleuteld naar buiten of wordt weggegooid, en alleen het charon-log klaagt.
De externe host weet niets van uw tunnel
Binnen de externe LAN is het antwoord een gewoon pakket dat aan uw client is gericht. De bestemmingshost ziet geen IPsec-header en heeft geen reden om de VPN-gateway te verkiezen; hij zoekt uw prefix op, vindt niets specifieker dan zijn standaardroute en volgt die. Wijst de standaardroute naar een kernfirewall, dan heeft die firewall wel of geen route terug de tunnel in. Als die er niet is, krijgt u een stille drop, een ICMP unreachable of een antwoord dat via de internetinterface naar buiten gaat en sterft.
Een tweede interface is genoeg om dit te breken, zelfs als er een route bestaat. Een NAS met een beheerlink op een andere VLAN, een server met een back-uplink, een beleidsregel die één bronbereik naar een tweede tabel stuurt: elk daarvan kan het antwoord vangen. Op Linux tonen ip rule show en ip route show table all regels en tabellen die de standaardlijst verbergt.
Lees de beslissing op de machine die het antwoord verstuurt
Vraag het aan de kernel voordat u iets verandert, en geef hem het bronadres, want bronafhankelijke regels veranderen het antwoord.
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 )"De uitvoer noemt de uitgaande interface en de volgende hop. Is de interface niet degene die naar de VPN-gateway kijkt, dan hebt u het defect gevonden, en het resterende werk is kiezen waar de route hoort. Een ping vanaf de gateway bewijst hier weinig: hij antwoordt met een adres dat de externe host kan plaatsen, niet met het adres van uw laptop.
Op Windows zijn de equivalenten Find-NetRoute -RemoteIPAddress 10.10.5.10 voor de beslissing en Get-NetRoute voor de tabel. Een route die met New-NetRoute is toegevoegd en een hogere metriek heeft dan de standaard, verliest stil, dus lees de metriekkolom, niet de vermelding. Bevestig daarna met pakketten: tcpdump -ni any "host 10.10.5.10 and tcp port 445" op de externe LAN-interface toont het verzoek, en hetzelfde filter aan de tunnelkant toont of er een antwoord terugkwam. Verzoek zichtbaar zonder antwoord betekent dat het antwoord elders is gerouteerd of weggegooid; een antwoord op de verkeerde interface geeft u de schuldige voordat u een route aanraakt.
Wanneer de gateway van de server niet het VPN-eindpunt is
Veel locaties zetten een firewall tussen de servers en de concentrator. Die firewall stuurt het antwoord door, dus hij heeft een route nodig voor uw clientprefix naar de VPN-gateway, en doorstuurbeleid in beide richtingen. Stateful apparaten maken het erger: het verzoek stak de firewall over vanaf een LAN-host die hij toestond, het antwoord komt nu uit een andere richting, en de verbindingstracking-vermelding past niet meer, dus het pakket wordt als ongeldig weggegooid in plaats van geweigerd. Daarom lijkt het beleidslog leeg terwijl het verkeer verdwijnt.
De gateway heeft zijn eigen tweede filter. Linux’ reverse-pathfiltering gooit pakketten weg waarvan de bron niet bereikbaar is via de interface waarop ze aankwamen, en dat is precies de vorm van een legitieme asymmetrische retourweg. de doorstuurhandleiding van strongSwan vraagt om die reden net.ipv4.ip_forward en een versoepelde net.ipv4.conf.all.rp_filter. Een strikte waarde van 1 op een van beide gateways breekt stil een correcte route, en nstat -az toont de drops als u weet waar u moet kijken.
| Symptom | Where the reply is most likely lost |
|---|---|
| Gateway ping works, LAN host silent | Source address the far host cannot place in its table |
| SYN arrives, no SYN-ACK, tunnel counters flat | No route to the client prefix on the far host or its gateway |
| Reply counted on the internet-facing interface | Default route or policy rule on the far host |
| Firewall reports invalid state | Asymmetric path through a stateful device |
| Worked until a link failed over | New path is asymmetric, or rp_filter now rejects it |
Routeer of vertaal, en verifieer daarna in beide richtingen
De twee reparaties zijn niet gelijkwaardig. Een route toevoegen laat het clientadres intact, dus brongebaseerde regels, auditlogs en applicaties die de beller vastleggen blijven werken; de prijs is dat elke hop die de beslissing neemt de route nodig heeft, wat meer plekken is om fout te zijn. Maskerade op de externe gateway perst de retourweg samen tot één hop, omdat het antwoord nu aan de gateway zelf is gericht, en verbergt welke client wat deed.
iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADEKies het bewust: zodra clients als het gatewayadres verschijnen, kunnen brongebaseerde ACL’s hen niet meer onderscheiden, en conntrack moet de mapping vasthouden zodat het antwoord terug de tunnel in wordt geschreven. Als de selectors het clientprefix nog steeds uitsluiten, verandert NAT niets, omdat het verzoek nooit in de tunnel is gekomen.
Voordat u het gerepareerd noemt, bevestigt u vier dingen in volgorde: de route op de host die het antwoord verstuurt, de route op elke hop die het doorstuurt, de selectors die beide prefixen dekken, en een opname die laat zien dat het antwoord de tunnel binnengaat met de bron die u verwacht. Herhaal daarna de test vanaf de andere locatie. Eén richting die werkt is een halfopen ontwerp, en de tweede richting faalt meestal om een andere reden dan degene die u net hebt gerepareerd.