Vad som ska dokumenteras för ett site-to-site-VPN: selektorer och omfång

Sex månader efter att en tunnel togs i drift slutar ett nytt subnät att matcha policyn, och det enda dokumentet på utdelningen säger kontors-VPN. Det är felet en selektorpost förebygger, och det är konkret: en adressuppsättning ändrades medan papperen inte gjorde det. Att skriva posten rätt innebär att veta vilken av flera adressuppsättningar du beskriver, och att anteckna den motparten faktiskt tillämpar i stället för den du konfigurerade.

Konfigurerat är inte förhandlat

I en policybaserad IPsec-tunnel föreslår varje sida trafikselektorer: käll- och målintervall för barnassociationen. Den svarande sidan får snäva in förslaget, så den installerade associationen kan täcka mindre än konfigurationen räknar upp. En post som kopierar konfigurationen beskriver en avsikt, inte det aktuella skyddsomfånget. De två glider isär tyst, och inget på tunnelns statussida pekar på det.

Behåll båda kolumnerna, med datumet du observerade dem. Den konfigurerade selektorn är vad du menade; den förhandlade är vad kärnan tillämpar just nu. När de skiljer sig förklarar den skillnaden ett oväntat fel mycket oftare än en routningsbugg gör.

En association representerar inte heller varje konfigurerat par. En tunnel med flera selektorkombinationer kan sluta med flera barnassociationer, och en post som listar en av dem är en ofullständig inventering. Räkna upp dem i stället för att sammanfatta dem.

Ruttbaserade tunnlar väljer annorlunda

Med ett ruttbaserat gränssnitt avgör routingtabellen vad som kommer in i tunneln, och selektorerna kan vara avsiktligt breda. Det är en legitim konstruktion och inte slarv, och posten måste beskriva den som just det. Skriv ned rutten, gränssnittet den pekar på, och brandväggspolicyn som begränsar vilka tjänster som är nåbara. Skyddsomfånget är brett med avsikt, och tjänsteomfånget gör insnävningen.

Att kopiera en policybaserad mall till en ruttbaserad tunnel ger ett dokument som beskriver en mekanism som driftsättningen inte använder. Nästa ingenjör letar då efter selektorer som aldrig var menade att finnas där, och drar slutsatsen att tunneln är felkonfigurerad när den bara är dåligt dokumenterad.

Översättning hör hemma i samma tabell

När NAT visar motparten ett annat intervall, anteckna de ursprungliga och de översatta prefixen tillsammans. Notera i vilket steg selektorerna och åtkomstreglerna matchar dem, eftersom ordningen avgör om den andra sidan någonsin ser adressen du skrev ned. En tabell med bara ett av de två intervallen är sämre än ingen tabell, eftersom den ser fullständig ut.

Det här är detaljen som bryter en fungerande tunnel efter en NAT-ändring: selektorn matchar fortfarande det ursprungliga prefixet, motparten tar nu emot ett översatt, och dess returrutt pekar på en adress som inte längre finns. Inget loggar ett fel i stunden då de slutar stämma överens.

Privat DNS hör hemma på samma ställe. Ett namn som löses till en adress som är oanvändbar från den aktuella platsen är ett dokumentationsfel med en supportbiljett bifogad, och det kommer att skyllas på tunneln.

Bifoga tjänstekravet

Ett skyddat intervall är inte en behörighetslista. Skriv ned vilka tjänster som ska vara nåbara från vilken källa, och vem som äger applikationen bakom dem. De två fälten svarar på olika frågor, och att blanda dem är hur en säkerhetsgranskning slutar argumentera om routning i stället för åtkomst.

Namnge sedan nätverksadministratören som underhåller regeln. En selektorinventering utan ägare blir tyst inaktuell, och inaktuell går inte att skilja från fel när tunneln rasar klockan två på natten. Ägaren är också den som kan bekräfta att en ändring var avsiktlig.

Gör posten till en testplan

För varje krävd väg, välj en representativ käll- och målvärd och notera förväntad rutt, tjänst och svarsgateway. Det gör dokumentet till en testplan i stället för en beskrivning. Läs tillbaka den aktiva associationen med kommandot nedan, och jämför den med den förhandlade rad du skrev ned.

swanctl --list-sas

Ett skelett på fem rader räcker oftast för att hålla posten ärlig. Versionen nedan får plats i en ändringsbiljett utan att kortas av:

sites: office <-> dc1
configured selector: 10.10.0.0/16 <-> 10.20.0.0/16
negotiated selector: 10.10.4.0/22 <-> 10.20.0.0/16
translated range: 172.16.4.0/22 -> 10.10.4.0/22
service and owner: erp:443 / finance-netops

En ping bara till gatewayen är inte acceptanstestet. Den prövar aldrig transitvägen, så den kan passera medan varje vidarebefordrat flöde misslyckas. Testa från en värd på ena sidan till en tjänst på den andra och bekräfta att svaret kommer genom tunneln. Om bara pinget passerar har posten just hittat vidarebefordringsproblemet den skrevs för att förebygga. strongSwans dokumentation om vidarebefordran förklarar hur selektorer, rutter och vidarebefordran samverkar på en Linux-peer.