strongSwan vips: at bede IKEv2 om en virtuel adresse

Din IKEv2-klient kan bede gatewayen om en intern adresse, og gatewayen bestemmer, hvad den sender tilbage. I strongSwan er den anmodning indstillingen vips, og den forbliver en anmodning, selv når du skriver en bestemt adresse ind i den. Runbooken nedenfor konfigurerer anmodningen, indlæser den og læser, hvad der kom tilbage, fordi de tre trin fejler på tre forskellige måder. Ingen af dem bliver kortere af at skrive hårdere.

Hvad vips beder om, og hvad det ikke kan love

vips hører inde i en forbindelsesdefinition og beder svareren om en virtuel adresse. strongSwans vejledning om virtuelle adresser er tydelig om, at svaret kan være en anden adresse eller slet ingenting, og det er den sætning, folk springer over, når de skriver en værdi og forventer, at den dukker op. Anmodningen er stadig værd at sende, fordi det er svaret, du kontrollerer. Behandl indstillingen som en instruks om at spørge, ikke som konfiguration af resultatet.

At anmode om 0.0.0.0 beder om en hvilken som helst ledig virtuel IPv4-adresse, hvilket normalt er rigtigt, når den præcise værdi ikke betyder noget. At anmode om en bestemt adresse er et vink til gatewayen, ikke et krav til den.

swanctl-uddraget og hvor det hører til

Indstillingen sidder inde i forbindelsesblokken, ikke i sin egen fil og ikke i en operativsystemprofil. Dette isolerede uddrag viser formen:

connections {
  net {
    local_addrs = 192.0.2.10
    remote_addrs = 203.0.113.5
    vips = 10.77.0.31
    children {
      net { local_ts = dynamic remote_ts = 10.77.0.0/24 }
    }
  }
}

Indlæs det med den fil, der ejer forbindelsen, start derefter forbindelsen, og læs resultatet. Et uddrag, der indsættes i det forkerte afsnit, giver en parsefejl eller, værre, en forbindelse, der indlæses uden den anmodning, du troede, du havde lavet. Kør de tre kommandoer i rækkefølge, og gem outputtet.

swanctl --load-all --file /etc/swanctl/swanctl.conf
swanctl --initiate --child net
swanctl --list-sas

local_ts vælger trafik, det skaber ikke en adresse

local_ts angiver det sæt trafik, som den underordnede SA beskytter; det sætter ikke en adresse på en grænseflade. Når en virtuel IP er forhandlet, holder strongSwan op med at bruge sin standarddynamiske vælger og bruger i stedet den tildelte adresse. Fastlåser du vælgeren til en bogstavelig adresse, hævder du noget, som gatewayen måske ikke har tildelt, og derfor viser fejlen sig som en fungerende SA med trafik, der ikke fører nogen steder. Vælgeren beskriver trafik, mens tildelingen kommer fra den anden udveksling.

Den anden måde at få en stabil intern adresse på er at eje den lokalt. Sæt adressen på en grænseflade, før tunnelen kommer op, peg vælgeren på det, der allerede findes, og arrangér peer og rute omkring det.

Intet forhandles i det design, så intet kan tildeles igen, og det er byttet: determinisme for selv at udføre adresseringsarbejdet. Det er en anden mekanisme, ikke en variant af vips, og derfor bør de to ikke blandes i én forbindelse. En fastlåst vælger ved siden af en forhandlet adresse er en forbindelse, der virker, indtil gatewayen udleverer noget andet.

Kontrollér, hvad svareren faktisk tildelte

Læs SA-listen for den adresse, gatewayen tildelte, og bekræft derefter, at adressen findes på grænsefladen. Hvis de to ikke stemmer overens, er tunnelen oppe, og trafikken går ikke, hvor du tror. En tildelt adresse, der aldrig når grænsefladen, er den mest forvirrende fejl i denne sekvens, fordi hver halvdel ser korrekt ud alene.

Hold fire adresser adskilt i dine noter: den anmodede interne adresse, den tildelte, maskinens LAN-adresse og den offentlige udgang, som et websted rapporterer. De hører til forskellige lag og optræder forskellige steder. En runbook, der registrerer alle fire, er en, som en anden kan følge uden at spørge, hvilken adresse du mente. Læs dem igen efter hver genindlæsning, fordi den tildelte værdi er den eneste, der beskriver den levende tunnel.

Hold det statiske design adskilt

Hvis du har brug for en fast intern adresse, så arrangér reservationen på gatewayen, og lad klientens anmodning være en anmodning. Bliver en fastlåst vælger blandet med en forhandlet adresse, får du en forbindelse, der virker, indtil gatewayen tildeler noget andet. Skriv reservationsreglen ned ved siden af forbindelsen, fordi det er den del, en kollega ikke kan udlede af konfigurationsfilen. Så arver en ny klient reglen i stedet for at genopdage den.

På den indbyggede Mac-klient findes ingen af disse indstillingsnavne. Brug den tildeling eller reservation, gatewayen tilbyder, og den profil, operatøren offentliggør, og behandl enhver værdi på klientsiden som et vink, indtil du har læst tildelingen tilbage. Rollback er at fjerne vips-linjen og genindlæse, hvilket bringer dig tilbage til det, gatewayen tildeler som standard.