strongSwan vips: IKEv2 om een virtueel adres vragen

Je IKEv2-client kan de gateway om een intern adres vragen, en de gateway bepaalt wat er terugkomt. In strongSwan is die aanvraag de instelling vips, en het blijft een aanvraag, ook als je er een specifiek adres in schrijft. De runbook hieronder configureert de aanvraag, laadt hem en leest wat er terugkwam, omdat die drie stappen op drie verschillende manieren mislukken. Geen ervan wordt korter door harder te typen.

Wat vips vraagt, en wat het niet kan beloven

vips hoort binnen een verbindingsdefinitie en vraagt de responder om een virtueel adres. De strongSwan-gids over virtuele adressen zegt uitdrukkelijk dat het antwoord een ander adres kan zijn, of helemaal niets, en dat is precies de zin die mensen overslaan wanneer ze een waarde invullen en verwachten dat die verschijnt. De aanvraag is nog steeds de moeite waard, want je controleert het antwoord. Behandel de instelling als een opdracht om te vragen, niet als de configuratie van het resultaat.

Om 0.0.0.0 vragen vraagt om elk beschikbaar virtueel IPv4-adres, wat meestal klopt als de exacte waarde er niet toe doet. Om een specifiek adres vragen is een hint aan de gateway, geen eis aan de gateway.

Het swanctl-fragment en waar het hoort

De instelling staat in het verbindingsblok, niet in een eigen bestand en niet in een besturingssysteemprofiel. Dit geïsoleerde fragment toont de vorm:

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 }
    }
  }
}

Laad het met het bestand dat de verbinding bezit, start daarna de verbinding en lees het resultaat. Een fragment dat in de verkeerde sectie wordt geplakt, levert een parsefout op of, erger, een verbinding die laadt zonder de aanvraag waarvan je dacht dat je die had gedaan. Voer de drie opdrachten op volgorde uit en bewaar de uitvoer.

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

local_ts kiest verkeer, het maakt geen adres

local_ts benoemt de set verkeer die de child-SA beschermt; het zet geen adres op een interface. Zodra een virtueel IP is onderhandeld, stopt strongSwan met het gebruik van zijn standaard dynamische selector en gebruikt in plaats daarvan het toegekende adres. Als je de selector vastzet op een letterlijk adres, beweer je iets wat de gateway misschien niet heeft toegekend, en daarom verschijnt de fout als een werkende SA met verkeer dat nergens heen gaat. De selector beschrijft verkeer, terwijl de toewijzing uit de andere uitwisseling komt.

De andere manier om een stabiel intern adres te krijgen, is het lokaal te bezitten. Zet het adres op een interface voordat de tunnel omhoog komt, richt de selector op wat al bestaat, en regel de peer en de route eromheen.

In dat ontwerp wordt niets onderhandeld, dus niets kan opnieuw worden toegewezen, en dat is de ruil: determinisme in ruil voor zelf het adresseringswerk doen. Het is een ander mechanisme, geen variant van vips, en daarom moeten de twee niet in één verbinding worden gemengd. Een vastgezette selector naast een onderhandeld adres is een verbinding die werkt tot de gateway iets anders uitgeeft.

Controleer wat de responder werkelijk heeft toegewezen

Lees de SA-lijst voor het adres dat de gateway heeft toegekend, en bevestig dan dat het adres op de interface bestaat. Als de twee niet overeenkomen, staat de tunnel omhoog en gaat het verkeer niet waar je denkt. Een toegekend adres dat nooit de interface bereikt, is de meest verwarrende fout in deze reeks, omdat elke helft op zichzelf correct lijkt.

Houd vier adressen apart in je notities: het aangevraagde interne adres, het toegekende, het LAN-adres van de machine en de openbare uitgang die een website meldt. Ze horen bij verschillende lagen en verschijnen op verschillende plaatsen. Een runbook dat alle vier vastlegt, is er een die iemand anders kan volgen zonder te vragen welk adres je bedoelde. Lees ze na elke herlaadbeurt opnieuw, want de toegekende waarde is de enige die de levende tunnel beschrijft.

Houd het statische ontwerp apart

Als je een vast intern adres nodig hebt, regel dan de reservering op de gateway en laat de aanvraag van de client een aanvraag blijven. Een vastgezette selector met een onderhandeld adres mengen geeft een verbinding die werkt tot de gateway iets anders toewijst. Schrijf de reserveringsregel naast de verbinding, want dat is het deel dat een collega niet uit het configuratiebestand kan afleiden. Dan erft een nieuwe client de regel in plaats van die opnieuw te ontdekken.

Op de ingebouwde Mac-client bestaat geen van deze optienamen. Gebruik de toewijzing of reservering die de gateway biedt en het profiel dat de operator publiceert, en behandel elke waarde aan de clientkant als een hint tot je de toewijzing hebt teruggelezen. Terugdraaien betekent de vips-regel verwijderen en opnieuw laden, wat je terugbrengt naar wat de gateway standaard toewijst.