IPsec med flera subnät tappar returtrafik? Räkna reqid:na

Trafik lämnar den ena platsen och kommer aldrig tillbaka, båda gateways rapporterar en slutförd förhandling, och den enda ledtråden är en hög utgående paket utan svar. På en Linux-endpoint är den vanliga orsaken inte krypteringsstyrkan, MTU:n eller en routingtabell. Det är granulariteten hos policy-posterna och numret som kopplar varje policy till en säkerhetsassociation. Rutinen nedan läser de två databaserna innan något annat rörs.

Dela upp symptomet innan du ändrar något

Ett enkelriktat fel med en slutförd IKE-förhandling begränsar problemet till datavägen. Antingen matchade den utgående policyn och svaret kastades, eller så kom svaret aldrig fram eftersom andra sidan inte hade något att skicka det genom. Från en applikation ser båda likadana ut, och xfrm-databaserna skiljer dem åt.

Börja inte med MTU:n. En felaktig MTU ger hack och fragmenteringssymptom, inte en ren riktningsdelning med stigande utgående räknare.

Läs policy-databasen och state-databasen

Kryptering på Linux avgörs av policy-poster, så en matchande policy, inte en rutt, är det som för in ett paket i tunneln. Kör ip xfrm policy för att se selectors, riktning, prioritet och mall för varje post, och ip xfrm state för att se de etablerade associationerna med deras reqids. Policyn och associationen kopplas samman av den reqid:en.

Titta på alla tre riktningarna. Utgående och inkommande täcker trafik till och från den här värden; forward-riktningen spelar roll när värden routar åt andra. En saknad eller avvikande post i en riktning förklarar ett enkelriktat resultat utan något kryptografiskt fel.

Den klassiska asymmetrin: en reqid för flera subnät

Ett vanligt fel kommer från en peer som installerar policyer för alla förhandlade subnät under en enda reqid, vilket händer med racoons generate_policy require. Trafiken går då ut genom den association som skapades sist, medan andra sidan behåller en separat association per subnät. Svar anländer på en association vars reqid inte pekar ut den policy som borde acceptera dem, och kärnan kastar dem efter dekryptering.

Lösningen är en konfigurationsändring, inte en brandväggsregel: generate_policy unique; ger varje policy sin egen reqid, så att peerns associationer per policy har matchande partner. Tillämpa det, förhandla om, och räkna de distinkta reqid:na för de subnät du förväntar dig innan du förklarar framgång.

Om två subnät fortfarande delar en reqid medan andra sidan förväntar sig två, har du hittat asymmetrin. Anteckna kopplingen, för den är beviset på om nästa ändring rättade den eller bevarade den.

Selectors kommer från förhandlingen, inte från din konfiguration

De skyddade intervallen är vad båda sidor kom överens om, inte vad någon av sidorna bad om. En klient som erbjuder ett värdpar mot ett brett fjärrintervall får gatewayens snävade version, och klienten kan inte vidga den. Läs de installerade selectors i stället för dem i din lokala fil.

När målet är det motsatta, att hålla en destination utanför tunneln, lägg till en bypass-policy med ett lägre prioritetsnummer så att den vinner över den automatiskt installerade posten. En policy utan mall tillåter klartext, vilket gör den till ett medvetet undantag för en ändringsregistrering i stället för ett felsökningssteg.

Kontrollera i den här ordningen, och vet hur du backar ur

Lista policyer för varje subnät i båda riktningarna, inklusive forward om värden routar. Räkna distinkta reqids och bekräfta en per policy på den sida som förväntar sig det. Jämför installerade selectors med de förhandlade. Läs räknare per association igen efter en rekey, för den association du undersökte kan redan vara borta. Kontrollera rutter sist, eftersom en saknad rutt till fjärrsubnätet ger ett liknande enkelriktat symptom med rena policyräknare.

Innan du ändrar peern, spara den aktuella utdatan från båda xfrm-kommandona. Om den nya inställningen inte återställer returriktningen är det att återställa den utdatan en snabbare återrullning än att bygga om tunneln ur minnet, och det håller jämförelsen ärlig.