Varför en OpenVPN-rutt förlorar mot en strongSwan XFRM-policy

Paket kan följa en OpenVPN-rutt och ändå fångas av en IPsec-policy, och den kombinationen ser ut som ett routingfel från alla vinklar utom den rätta. Linux löser en rutt och konsulterar sedan en separat databas med säkerhetspolicyer, så en mer specifik destinationsrutt tränger inte undan en matchande XFRM-policy. Det synliga symptomet är trafik som lämnar värden och aldrig kommer fram, medan båda tunnlarna rapporterar sig friska. Tre alternativ löser det, och vilket du väljer beror på vilken av de två vägarna som ska bära det prefixet.

Två beslut, inte ett

Ruttval svarar på en smal fråga: vilket nästa hopp och vilken källadress som ska bära detta paket. Säkerhetspolicydatabasen svarar på en annan: kräver detta paket IPsec-skydd, och under vilka selektorer. Båda körs för samma paket, och att uppfylla det första säger inget om det andra. Därför kan en ändrad metrik eller en extra statisk rutt lämna symptomet orört.

En bred IPsec-selektor är den vanliga orsaken. En policy som skyddar 172.16.0.0/12 täcker även 172.20.8.0/24, som en administratör kanske vill nå genom OpenVPN-tunneln i stället. Avsikten finns bara i routingtabellen, och policydatabasen har aldrig fått veta om den.

Behandla det som en konflikt mellan två konfigurerade skyddsvägar och inte som en tävling mellan två metriker. Rättelsen hör hemma i den komponent som konfigurerades med fel omfattning.

Läs rutten som kärnan faktiskt väljer

Börja med den sökning som kärnan gör, inklusive källadressen och varje policyregel som kan leda den till en annan tabell. En rutt i huvudtabellen kanske aldrig konsulteras om en tidigare regel väljer en annan tabell, och matchning på längsta prefix gäller bara inom den tabell en regel väljer.

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

Det sista kommandot är det som betyder något, eftersom det skriver ut den valda rutten tillsammans med den källadress som kärnan skulle använda. Jämför den utskriften med den selektor som IPsec-policyn matchar. När rutten pekar på OpenVPN-gränssnittet och policyn fortfarande matchar samma par har du återskapat konflikten utan att gissa.

Håll dumpar fria från orelaterade adresser innan de når ett ärende. En routingtabell från en produktionsvärd bär intern topologi, och bara de rader som svarar på frågan är värda att klistra in.

Läs också policyn som gäller

Policylistan visar riktning, selektorer och mallen som avgör vad som händer med ett matchande paket. Läs utgående riktning först, sedan ingångssidan för returtrafiken, eftersom ett enkelriktat undantag ger en anslutning som börjar och aldrig slutförs.

ip -s xfrm policy
swanctl --list-sas

Jämför selektorerna i listan med de prefix som anslutningen förhandlade. Att stänga av strongSwans ruttinstallation tar inte bort dessa policyer, och en ändrad metrik ändrar inte vilket käll- och målpar en policy skyddar. De två falska rättelserna är värda att utesluta tidigt, eftersom det är dem folk prövar först.

Om listan inte innehåller någon policy för det prefix du förväntade dig ligger problemet någon annanstans, och routingtabellen säger förmodligen sanningen. Om den innehåller en bredare policy som täcker prefixet har du hittat fångsten.

Tre alternativ när båda vägarna är legitima

Att begränsa IPsec-selektorn är det renaste alternativet när det breda prefixet var en bekvämlighet och inte ett krav. Att minska selektorn för fjärrtrafik till de subnät som verkligen hör hemma bakom IPsec tar bort konflikten för varje värd på en gång, och det kostar en ny nyckelförhandling i stället för en ny komponent.

Ett passthrough-undantag är det kirurgiska alternativet när den breda selektorn måste bestå. strongSwan stöder en separat anslutning vars barn använder pass-läge, vilket talar om för kärnan att den matchande trafiken inte får behandlas av IPsec. Loopback-fjärradressen hindrar den anslutningen från att väljas för inkommande parter, och selektorerna måste beskriva det faktiskt auktoriserade paret i stället för allt.

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
            }
        }
    }
}

strongSwan-konfigurationsexemplen dokumenterar denna policytyp och loopback-partkonventionen. Det tredje alternativet är en ruttbaserad design med XFRM-gränssnitt, som binder policy till trafik som routas genom ett namngivet gränssnitt i stället för till en global selektor. Det är en migrering och inte en justering, och trafiken måste fortfarande uppfylla de förhandlade selektorerna.

Bevisa undantaget utan att försvaga resten

Efter att ändringen laddats, testa undantaget och en vanlig destination som måste förbli skyddad. Kontrollera båda riktningarna, släpp sedan OpenVPN-tunneln och bekräfta vad som händer med den undantagna trafiken. Ett undantag som tyst skickar det prefixet i klartext när tunneln är nere är ett policybeslut du bör fatta med avsikt, inte upptäcka under en incident.

Notera vilket prefix som använder vilken väg och varför. Annars kommer nästa ingenjör som ser en bred selektor att öppna samma utredning igen, och svaret kommer att ligga i ett commit-meddelande som ingen läser.