Waarom een OpenVPN-route verliest van een strongSwan XFRM-beleid

Pakketten kunnen een OpenVPN-route volgen en toch door een IPsec-beleid worden onderschept, en die combinatie ziet er vanuit elke hoek als een routingfout uit behalve vanuit de juiste. Linux lost een route op en raadpleegt daarna een aparte database met beveiligingsbeleid, dus een specifiekere bestemmingsroute verdringt geen overeenkomend XFRM-beleid. Het zichtbare symptoom is verkeer dat de host verlaat en nooit aankomt, terwijl beide tunnels zich gezond melden. Drie opties lossen het op, en welke je kiest hangt af van welk van de twee paden dat prefix moet dragen.

Twee beslissingen, niet één

Routekeuze beantwoordt een smalle vraag: welke volgende hop en welk bronadres dit pakket moeten dragen. De beleidsdatabase beantwoordt een andere: vereist dit pakket IPsec-bescherming, en onder welke selectors. Beide draaien voor hetzelfde pakket, en aan de eerste voldoen zegt niets over de tweede. Daarom kan een gewijzigde metriek of een extra statische route het symptoom ongemoeid laten.

Een brede IPsec-selector is de gebruikelijke oorzaak. Een beleid dat 172.16.0.0/12 beschermt, dekt ook 172.20.8.0/24, dat een beheerder misschien liever via de OpenVPN-tunnel wil bereiken. De bedoeling bestaat alleen in de routingtabel, en de beleidsdatabase heeft er nooit van geweten.

Behandel dat als een conflict tussen twee geconfigureerde beschermingspaden en niet als een wedstrijd tussen twee metrieken. De correctie hoort bij de component die met de verkeerde scope is geconfigureerd.

Lees de route die de kernel werkelijk kiest

Begin bij de opzoeking die de kernel doet, inclusief het bronadres en elke beleidsregel die het naar een andere tabel kan leiden. Een route in de hoofdtabel wordt misschien nooit geraadpleegd als een eerdere regel een andere tabel kiest, en langste-prefix-overeenkomst geldt alleen binnen de tabel die een regel kiest.

ip rule show
ip route show table all
ip route get 172.20.8.20 from 10.44.7.15

Het laatste commando is het belangrijkste, omdat het de gekozen route samen met het bronadres afdrukt dat de kernel zou gebruiken. Vergelijk die uitvoer met de selector waar het IPsec-beleid op past. Wanneer de route naar de OpenVPN-interface wijst en het beleid nog steeds op hetzelfde paar past, heb je het conflict gereproduceerd zonder te gokken.

Houd dumps vrij van ongerelateerde adressen voordat ze een ticket bereiken. Een routingtabel van een productiehost draagt interne topologie, en alleen de regels die de vraag beantwoorden zijn het waard om te plakken.

Lees ook het beleid dat geldt

De beleidslijst toont richting, selectors en de sjabloon die bepaalt wat er met een overeenkomend pakket gebeurt. Lees eerst de uitgaande richting, dan de inkomende kant voor het retourverkeer, want een eenrichtingsuitzondering levert een verbinding op die begint en nooit voltooid wordt.

ip -s xfrm policy
swanctl --list-sas

Vergelijk de selectors in de lijst met de prefixen die de verbinding heeft onderhandeld. Het uitschakelen van strongSwans route-installatie verwijdert die beleidsregels niet, en een gewijzigde metriek verandert niet welk bron- en bestemmingspaar een beleid beschermt. Die twee nep-oplossingen zijn het waard om vroeg uit te sluiten, want dat zijn de eerste dingen die mensen proberen.

Als de lijst geen beleid bevat voor het prefix dat je verwachtte, ligt het probleem elders en vertelt de routingtabel waarschijnlijk de waarheid. Als er een breder beleid in staat dat het prefix dekt, heb je de onderschepping gevonden.

Drie opties wanneer beide paden legitiem zijn

Het vernauwen van de IPsec-selector is de schoonste optie wanneer het brede prefix een gemak en geen vereiste was. Het verkleinen van de selector voor verafgelegen verkeer tot de subnetten die werkelijk achter IPsec horen, verwijdert het conflict voor elke host in één keer, en het kost een nieuwe sleutelonderhandeling in plaats van een nieuwe component.

Een passthrough-uitzondering is de chirurgische optie wanneer de brede selector moet blijven. strongSwan ondersteunt een aparte verbinding waarvan het child de pass-modus gebruikt, wat de kernel vertelt dat het overeenkomende verkeer niet door IPsec verwerkt mag worden. Het loopback-afstandsadres weerhoudt die verbinding ervan voor inkomende peers te worden gekozen, en de selectors moeten het echt geautoriseerde paar beschrijven in plaats van alles.

connections {
    openvpn-exception {
        remote_addrs = 127.0.0.1
        children {
            openvpn-exception {
                local_ts = 10.44.7.0/24
                remote_ts = 172.20.8.0/24
                mode = pass
                start_action = trap
            }
        }
    }
}

De strongSwan-configuratievoorbeelden documenteren dit beleidstype en de loopback-peer-conventie. De derde optie is een op routing gebaseerd ontwerp met XFRM-interfaces, dat beleid koppelt aan verkeer dat via een genoemde interface wordt gerouteerd in plaats van aan een globale selector. Het is een migratie en geen aanpassing, en het verkeer moet nog steeds aan de onderhandelde selectors voldoen.

Bewijs de uitzondering zonder de rest te verzwakken

Test na het laden van de wijziging de uitzondering en een gewone bestemming die beschermd moet blijven. Controleer beide richtingen, laat dan de OpenVPN-tunnel vallen en bevestig wat er met het uitgezonderde verkeer gebeurt. Een uitzondering die dat prefix stil in het openbaar verstuurt wanneer de tunnel plat ligt, is een beleidsbeslissing die je met opzet moet nemen, niet moet ontdekken tijdens een incident.

Noteer welk prefix welk pad gebruikt en waarom. Anders heropent de volgende engineer die een brede selector ziet hetzelfde onderzoek, en het antwoord staat in een commit-bericht dat niemand leest.