En innlastet strongSwan-profil er ikke en aktiv tunnel

Å liste en forbindelse i strongSwan-konfigurasjonen beviser bare at en definisjon er lastet inn. Det betyr ikke at motparten er kontaktet, at det finnes en IKE-SA, eller at noen trafikk er beskyttet. Daemonen behandler definisjoner og levende assosiasjoner som separate objekter, og avstanden mellom dem er et bevisst designvalg. Å vite hvilket objekt du undersøker gjør en vag feil til en konkret neste kommando.

Innlasting er ikke tilkobling

En innlastet forbindelse er en erklæring om hva som kan forhandles senere: motpartadresser, påloggingsinformasjon, forslag og trafikkvelgere. Ingenting i den erklæringen krever at daemonen har ringt noen. En gateway kan vente på den andre siden, initiere ved oppstart eller vente på at samsvarende trafikk vekker den. Alle tre er gyldige, og alle tre ser identiske ut i konfigurasjonsfilen til du leser startpolicyen.

Operatører kommer i trøbbel ved å lese definisjonslisten som en statusliste. Profilen er der, så tunnelen antas å være oppe, og den neste timen går med til å feilsøke ruter for en assosiasjon som aldri ble bygget.

Den motsatte feilen er like vanlig. En manglende profil sender folk på jakt etter en nettverksfeil når konfigurasjonen aldri ble lastet inn. Navngi objektet og kjør deretter kommandoen som observerer det.

Tre objekter, tre observasjoner

strongSwan holder en innlastet definisjon, en IKE-SA og en CHILD-SA. Den første er konfigurasjon, den andre er et autentisert kontrollforhold, og den tredje er forhandlet beskyttelse for valgt trafikk. De har til og med separate navn, så en profil som heter hq kan eie en child som heter hq-lan.

Tabellen kobler hvert lag til kommandoen som viser det. Les raden før du leser loggen.

Å be om childen bygger først dens overordnede IKE-SA når ingen finnes. Å bare be om IKE-SA-en er et annet kall. En kontrollkanal som autentiserer fint garanterer ikke childen du ba om.

Den forskjellen betyr noe ved en delvis feil. En IKE-SA kan være sunn mens childen feiler på et velgeravvik eller et forslag som motparten ikke godtar. De to objektene feiler av ulike grunner, så de fortjener separate observasjoner.

Velg starthandlingen bevisst

I swanctl.conf styrer en childs start_action atferden etter innlasting. Standarden none overlater definisjonen til manuell initiering eller responder-bruk. start ringer opp, mens trap etterlater en policy som forhandler så snart samsvarende trafikk dukker opp.

Så både 'innlasting starter aldri en tunnel' og 'innlasting starter alltid en' er feil. Handlingen er en del av profilen, og den bør passe motpartens rolle. To gateways som begge venter på den andre siden gir stillhet, ikke en tunnel.

Med trap må trafikken samsvare med velgerne, så en urelatert ping vekker ingenting. Med start må motpartadressen være brukbar, og begge sider må bli enige om autentisering og forslag. Ingen av handlingene erstatter kontrollen av disse forutsetningene.

Gjenoppretting er en egen policy

Oppstart er ikke en keepalive. Registrering av døde motparter, eksplisitt lukking fra motparten, rekeying og en prosessomstart er forskjellige livssyklushendelser med egne innstillinger. Konfigurer hver av dem bevisst i stedet for å forvente at en innledende start dekker alle.

En tunnel som kommer opp ved oppstart og dør en time senere er et gjenopprettingsspørsmål. Startpolicyen gjorde jobben sin og sluttet deretter å bety noe. Se på DPD- og rekey-innstillinger før du gir den innledende forhandlingen skylden.

Å erstatte innlastede definisjoner er en egen operasjon. Ikke-standard startpolicyer har dokumenterte inverse handlinger, og en omlasting er en driftsendring snarere enn en antakelse om at hver assosiasjon ble oppdatert på stedet. Gjennomfør omlastinger i trinn der en gjenoppkobling er akseptabel. Behold den gamle konfigurasjonen til den nye er bevist.

Kontroller hva som finnes før du feilsøker ruting

Kjør de tre observasjonene i rekkefølge: innlastede definisjoner, aktive IKE-SA-er og child-oppføringer. Hvert svar snevrer inn neste spørsmål. Hopp over et trinn og du ender med å feilsøke et lag som aldri ble bygget.

Begynn med det som er lastet inn, og det som faktisk er etablert:

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

Hvis childen mangler mens profilen er riktig, initier den ved navn og se hva som skjer. Utdataene sier vanligvis om den overordnede kom opp først.

swanctl --initiate --child hq-lan

En aktiv CHILD-SA er ikke målstreken. Videresendingsregler, ruter og applikasjonens egen autorisasjon må fortsatt stemme. Livssyklusen svarer på hva som ble forhandlet; den kan ikke avgjøre hvem som får bruke tjenesten.