strongSwan trap-modus: waarom de IPsec-tunnel op verkeer wacht

Een inactieve on-demand IPsec-tunnel toont geen CHILD SA tot een pakket bij zijn trap-beleid past. Lees de status, controleer de trigger en weet wanneer start past.

Er verschijnt geen CHILD SA in de statusuitvoer, de tunnel lijkt dood, en dan brengt een ping naar het externe subnet hem omhoog. In een on-demand IPsec-opstelling is die volgorde het ontwerp, geen storing. Een trap-beleid installeert een selector en wacht, en het eerste pakket dat erbij past, start IKE en de CHILD SA-onderhandeling.

Een deel van de verwarring is woordenschat: “up” wordt voor twee verschillende toestanden gebruikt. De configuratie is geladen en het kernelbeleid bestaat, maar de data-associatie niet. Een monitor die alleen actieve SA's telt, meldt een gezonde locatie als down zolang niemand er verkeer naartoe stuurt.

Een inactieve on-demand-tunnel heeft geen CHILD SA om te tonen

Een trap-item authenticeert op zichzelf niets. Het vraagt de kernel een beleid voor het geselecteerde verkeer te houden en een acquisition op te werpen wanneer een pakket dat beleid nodig heeft. De daemon ontvangt de acquisition, koppelt hem aan de child-definitie en onderhandelt vanaf daar. Tot dat moment is er ook geen IKE SA om te tonen, daarom kunnen beide lijsten tegelijk leeg zijn.

Die volgorde maakt de logs leesbaar. Eerst komt de acquisition, dan IKE_SA_INIT en IKE_AUTH, dan de CHILD SA. Eindigt het log direct na de acquisition, dan werkte de trigger. De onderhandeling is mislukt, en de volgende vraag gaat over inloggegevens, voorstellen of bereikbaarheid, niet over de trap.

Met de Linux-kernelbackend kunt u het beleid zien voordat er enige SA bestaat. Voer ip xfrm policy uit en zoek de selector met richting out en een sjabloon dat naar de verbinding wijst. Dat item is de on-demand-toestand, en de aanwezigheid ervan is het eerste dat bevestigd moet worden.

start_action bepaalt of er überhaupt iets wacht

Elke child in swanctl.conf draagt een start_action. start start bij het laden van de configuratie, trap installeert het beleid en wacht, en none laat het starten aan iets anders over. Alleen trap levert het hierboven beschreven gedrag “ping en hij komt omhoog”.

children {
    office-lan {
        local_ts = 192.168.50.0/24
        remote_ts = 192.168.70.0/24
        start_action = trap
    }
}

De twee verkeersselectors bepalen wat als interessant geldt, en een pakket van een host buiten die prefixen activeert de trap niet; het wordt zoals gewoonlijk gerouteerd. De selectors verbreden om de trigger gretiger te maken verbreedt ook het bereik dat de tunnel claimt te beschermen, dus leid ze af uit verkeer dat u echt wilt versleutelen.

De swanctl.conf-referentie vermeldt de geaccepteerde waarden, samen met de afzonderlijke close- en DPD-acties die bepalen wat er gebeurt zodra de SA bestaat.

Zoek uit of de trigger überhaupt is afgegaan

Begin met swanctl --list-conns en bevestig dat de child met de bedoelde actie is geladen. Stuur dan één pakket van een host binnen local_ts naar een adres binnen remote_ts en kijk naar swanctl --list-sas. Verandert de uitvoer niet, dan heeft geen acquisition de daemon bereikt.

Twee gewone redenen voor een stille trap: het pakket is source-NAT't voordat het het beleid raakte en past niet meer bij local_ts, of de verbinding is nooit geladen door een syntax- of inlogfout. Voer swanctl --load-all opnieuw uit en lees de uitvoer voordat u selectors aanraakt. Een verbinding die niet is geladen installeert geen beleid, dus er is niets dat het verkeer kan activeren.

De richting is ook belangrijk: een trap voor uitgaand verkeer start niet op een inkomend pakket. Als de externe kant de tunnel omhoog moet brengen, heeft die zijn eigen trap nodig, of deze kant heeft start.

Wachten op het eerste pakket is niet altijd de juiste ruil

Interactieve sessies merken de opzetkosten. Het eerste verzoek betaalt voor de IKE-uitwisseling en de CHILD-onderhandeling, en een client met een korte deadline kan opgeven voordat de SA bestaat. Proactief start haalt die vertraging van het eerste pakket weg. Maar het houdt een tunnel open voor verkeer dat misschien nooit komt.

Drie feiten beslissen de keuze: hoe vaak het pad wordt gebruikt, of het eerste verzoek een krappe deadline heeft en of de peer bij het opstarten bereikbaar is. Incidenteel batchverkeer en een peer die bij het opstarten offline kan zijn, pleiten beide voor trap. Een latentiegevoelige client en een peer die altijd bereikbaar is, pleiten voor start. Als beide kanten kunnen initiëren, spreek dan af wie de trigger bezit, zodat u geen dubbele onderhandelingen krijgt.

Een geïnstalleerd beleid is ook geen lekbestendige garantie. Als de eis fail-closed is, moet de firewall verkeer zonder SA laten vallen, en die regel leeft buiten de child-definitie.

Noteer de drie regels die de volgende discussie beëindigen

Schrijf de selectors, de startactie en de commandouitvoer op die het beleid zonder SA aanwezig toont. Die drie regels scheiden “on demand en inactief” van “laadt niet” de volgende keer dat iemand de tunnel als down meldt. Ze kosten een minuut om vast te leggen. Zonder hen begint hetzelfde onderzoek weer bij nul.

Test vanaf een host die echt binnen de selector valt. Een ping vanaf de router zelf volgt vaak een ander pad en bewijst niets over het beleid dat het subnet erachter beschermt.

Gerelateerde artikelen