strongSwan-trapmodus: waarom die IPsec-tonnel op verkeer wag

’n Onaktiewe vraaggestuurde IPsec-tonnel wys geen CHILD SA voordat ’n pakkie by sy trap-beleid pas nie. Lees die toestand, kontroleer die sneller en weet wanneer start pas.

Geen CHILD SA verskyn in die statusuitvoer nie, die tonnel lyk dood, en dan bring ’n ping na die verre subnet dit op. In ’n vraaggestuurde IPsec-opset is daardie volgorde die ontwerp, nie ’n fout nie. ’n Trap-beleid installeer ’n selektor en wag, en die eerste pakkie wat daarby pas, is wat IKE en die CHILD SA-onderhandeling begin.

Deel van die verwarring is woordeskat: “up” word vir twee verskillende toestande gebruik. Die konfigurasie is gelaai en die kernbeleid bestaan, maar die data-assosiasie nie. ’n Monitor wat net aktiewe SA’s tel, sal ’n gesonde terrein as af rapporteer solank niemand verkeer daarheen stuur nie.

’n Onaktiewe vraaggestuurde tonnel het geen CHILD SA om te wys nie

’n Trap-inskrywing verifieer niks op sigself nie. Dit vra die kern om ’n beleid vir die gekose verkeer te hou en ’n acquisition te lig wanneer ’n pakkie daardie beleid nodig het. Die daemon ontvang die acquisition, pas dit by die child-definisie en onderhandel van daar af. Tot op daardie punt is daar ook geen IKE SA om te wys nie, daarom kan albei lyste gelyktydig leeg wees.

Daardie volgorde is wat die logs leesbaar maak. Die acquisition kom eerste, dan IKE_SA_INIT en IKE_AUTH, dan die CHILD SA. As die log reg ná die acquisition eindig, het die sneller gewerk. Die onderhandeling het misluk, en die volgende vraag gaan oor geloofsbriewe, voorstelle of bereikbaarheid, nie oor die trap nie.

Met die Linux-kernas-agterkant kan jy die beleid sien voordat enige SA bestaan. Voer ip xfrm policy uit en soek die selektor met rigting out en ’n sjabloon wat na die verbinding wys. Daardie inskrywing is die vraaggestuurde toestand, en die teenwoordigheid daarvan is die eerste ding om te bevestig.

start_action bepaal of enigiets hoegenaamd wag

Elke child in swanctl.conf dra ’n start_action. start begin wanneer die konfigurasie laai, trap installeer die beleid en wag, en none laat die inisiasie aan iets anders oor. Net trap lewer die gedrag “ping en dit kom op” wat hierbo beskryf is.

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

Die twee verkeersselektore bepaal wat as interessant geld, en ’n pakkie van ’n gasheer buite daardie voorvoegsels aktiveer nie die trap nie; dit roeteer soos gewoonlik. Om die selektore te verbreed om die sneller gretiger te maak, verbreed ook die omvang wat die tonnel beweer te beskerm, dus lei hulle af uit verkeer wat jy werklik wil versleutel.

Die swanctl.conf-verwysing lys die aanvaarde waardes, saam met die afsonderlike close- en DPD-aksies wat bepaal wat gebeur sodra die SA bestaan.

Kom uit of die sneller hoegenaamd gewerk het

Begin met swanctl --list-conns en bevestig die child is gelaai met die aksie wat jy bedoel het. Stuur dan een pakkie van ’n gasheer binne local_ts na ’n adres binne remote_ts en kyk na swanctl --list-sas. As die uitvoer nie verander nie, het geen acquisition die daemon bereik nie.

Twee gewone redes vir ’n stil trap: die pakkie is bron-NAT voordat dit die beleid getref het en pas nie meer by local_ts nie, of die verbinding het nooit gelaai nie weens ’n sintaks- of geloofsbrief-fout. Voer swanctl --load-all weer uit en lees die uitvoer voordat jy aan selektore raak. ’n Verbinding wat nie gelaai het nie, installeer geen beleid nie, so daar is niks vir verkeer om te aktiveer nie.

Rigting maak ook saak: ’n trap wat vir uitgaande verkeer geïnstalleer is, inisieer nie op ’n inkomende pakkie nie. As die verre kant die tonnel moet opbring, het dit sy eie trap nodig, of hierdie kant het start.

Wag vir die eerste pakkie is nie altyd die regte ruil nie

Interaktiewe sessies merk die opstellingskoste. Die eerste versoek betaal vir die IKE-uitruiling en die CHILD-onderhandeling, en ’n kliënt met ’n kort spertyd kan opgee voordat die SA bestaan. Proaktiewe start verwyder daardie eerste-pakkie-vertraging. Dit hou ’n tonnel op vir verkeer wat dalk nooit arriveer nie.

Drie feite beslis die keuse: hoe dikwels die pad gebruik word, of die eerste versoek ’n stywe spertyd het, en of die eweknie by die opstart bereikbaar is. Geleentheidsbatswerkeer en ’n eweknie wat dalk by opstart aflyn is, bevoordeel albei trap. ’n Latenis-sensitiewe kliënt en ’n eweknie wat altyd bereikbaar is, bevoordeel start. As albei kante kan inisieer, kom ooreen wie die sneller besit sodat jy nie dubbele onderhandelinge kry nie.

’n Geïnstalleerde beleid is ook nie ’n lekbestande waarborg nie. As die vereiste fail-closed is, moet die vuurmuur verkeer laat val wat geen SA het nie, en daardie reël leef buite die child-definisie.

Skryf die drie reëls neer wat die volgende argument beëindig

Skryf die selektore neer, die opstartaksie en die opdraguitvoer wat wys die beleid bestaan sonder ’n SA. Daardie drie reëls skei “op aanvraag en onaktief” van “laai nie” die volgende keer dat iemand die tonnel as af rapporteer. Dit kos ’n minuut om vas te vang. Sonder hulle begin dieselfde ondersoek van nul af.

Toets vanaf ’n gasheer wat werklik binne die selektor is. ’n Ping vanaf die router self volg dikwels ’n ander pad en bewys niks oor die beleid wat die subnet agter hom beskerm nie.

Verwante artikels