At liste en forbindelse i strongSwan-konfigurationen beviser kun, at en definition er indlæst. Det betyder ikke, at peeren er kontaktet, at der findes en IKE-SA, eller at nogen trafik er beskyttet. Daemonen behandler definitioner og levende associationer som separate objekter, og afstanden mellem dem er et bevidst designvalg. At vide, hvilket objekt du undersøger, gør en vag fejl til en konkret næste kommando.

Indlæsning er ikke forbindelse

En indlæst forbindelse er et udsagn om, hvad der senere kan forhandles: peeradresser, legitimationsoplysninger, forslag og trafikvælgere. Intet i det udsagn kræver, at daemonen har ringet til nogen. En gateway kan vente på den anden side, starte ved opstart eller vente på, at matchende trafik vækker den. Alle tre er gyldige, og alle tre ser identiske ud i konfigurationsfilen, indtil du læser startpolitikken.

Operatører kommer i problemer ved at læse definitionslisten som en statusliste. Profilen er der, så tunnelen antages at være oppe, og den næste time går med at fejlfinde ruter for en association, der aldrig blev bygget.

Den modsatte fejl er lige så almindelig. En manglende profil sender folk på jagt efter en netværksfejl, når konfigurationen aldrig blev indlæst. Navngiv objektet, og kør derefter den kommando, der observerer det.

Tre objekter, tre observationer

strongSwan holder en indlæst definition, en IKE-SA og en CHILD-SA. Den første er konfiguration, den anden er et autentificeret kontrolforhold, og den tredje er forhandlet beskyttelse af udvalgt trafik. De har endda separate navne, så en profil ved navn hq kan eje et child ved navn hq-lan.

Tabellen knytter hvert lag til den kommando, der viser det. Læs rækken, før du læser loggen.

LayerWhat it containsCommand
DefinitionPeer addresses, credentials, proposals, and traffic selectorsswanctl --list-conns
IKE SAOne authenticated control channel to the peerswanctl --list-sas
CHILD SAKeys and selectors for the traffic being protectedChild rows under the IKE SA

Når du anmoder om childen, bygges dens overordnede IKE-SA først, hvis der ikke findes nogen. Kun at anmode om IKE-SA'en er et andet kald. En kontrolkanal, der autentificerer pænt, garanterer ikke den child, du bad om.

Forskellen betyder noget ved en delvis fejl. En IKE-SA kan være sund, mens childen fejler på en vælgeruoverensstemmelse eller et forslag, som peeren ikke accepterer. De to objekter fejler af forskellige grunde, så de fortjener separate observationer.

Vælg starthandlingen bevidst

I swanctl.conf bestemmer en childs start_action adfærden efter indlæsning. Standarden none overlader definitionen til manuel initiering eller responder-brug. start ringer op, mens trap efterlader en politik, der forhandler, så snart matchende trafik dukker op.

Så både 'indlæsning starter aldrig en tunnel' og 'indlæsning starter altid en' er forkert. Handlingen er en del af profilen, og den bør passe til peerens rolle. To gateways, der begge venter på den anden side, producerer tavshed, ikke en tunnel.

Med trap skal trafikken matche vælgerne, så en uvedkommende ping vækker intet. Med start skal peeradressen være brugbar, og begge sider skal være enige om autentificering og forslag. Ingen af handlingerne erstatter kontrol af disse forudsætninger.

Genopretning er en separat politik

Opstart er ikke en keepalive. Registrering af døde peers, eksplicit lukning fra peeren, rekeying og en procesgenstart er forskellige livscyklushændelser med deres egne indstillinger. Konfigurer hver af dem bevidst i stedet for at forvente, at en indledende start dækker dem alle.

En tunnel, der kommer op ved boot og dør en time senere, er et genopretningsspørgsmål. Startpolitikken gjorde sit arbejde og holdt derefter op med at betyde noget. Se på DPD- og rekey-indstillinger, før du bebrejder den indledende forhandling.

At erstatte indlæste definitioner er sin egen operation. Ikke-standard startpolitikker har dokumenterede inverse handlinger, og en reload er en driftsmæssig ændring snarere end en antagelse om, at hver association blev opdateret på stedet. Udfør reloads i faser, hvor en genopkobling er acceptabel. Behold den gamle konfiguration, indtil den nye er bevist.

Kontroller, hvad der findes, før du fejlfinder routing

Kør de tre observationer i rækkefølge: indlæste definitioner, aktive IKE-SA'er og child-poster. Hvert svar indsnævrer det næste spørgsmål. Spring et trin over, og du ender med at fejlfinde et lag, der aldrig blev bygget.

Begynd med det, der er indlæst, og det, der faktisk er etableret:

swanctl --list-conns
swanctl --list-sas

Hvis childen mangler, mens profilen er korrekt, så initier den ved navn og se, hvad der sker. Outputtet siger normalt, om den overordnede kom op først.

swanctl --initiate --child hq-lan

En aktiv CHILD-SA er ikke målstregen. Videresendelsesregler, ruter og applikationens egen autorisation skal stadig passe sammen. Livscyklussen svarer på, hvad der blev forhandlet; den kan ikke afgøre, hvem der må bruge tjenesten.

Relaterede artikler