Hvad der skal registreres for en VPN mellem lokationer: selektorer og omfang

Seks måneder efter at en tunnel blev taget i brug, holder et nyt subnet op med at matche politikken, og det eneste dokument på drevet siger kontor-VPN. Det er den fejl, en selektorregistrering forhindrer, og den er konkret: et adressesæt ændrede sig, mens papirerne ikke gjorde. At skrive registreringen korrekt betyder at vide, hvilket af flere adressesæt du beskriver, og at notere det, som modparten faktisk håndhæver, frem for det, du konfigurerede.

Konfigureret er ikke forhandlet

I en politikbaseret IPsec-tunnel foreslår hver side trafikselektorer: kilde- og destinationsområder for den underordnede associering. Den svarande side må indsnævre dette forslag , så den installerede associering kan dække mindre, end konfigurationen angiver. En registrering, der kopierer konfigurationen, beskriver derfor en hensigt, ikke det aktuelle beskyttelsesomfang. De to divergerer stille, og intet på tunnelens statusside peger på det.

Behold begge kolonner med den dato, du observerede dem. Den konfigurerede selektor er det, du mente; den forhandlede er det, kernen håndhæver lige nu. Når de afviger, forklarer den forskel en overraskende fejl langt oftere, end en routingfejl gør.

En associering repræsenterer heller ikke hvert konfigureret par. En tunnel med flere selektorkombinationer kan ende med flere underordnede associeringer, og en registrering, der nævner én af dem, er en delvis fortegnelse. Optæl dem i stedet for at opsummere dem.

Rutebaserede tunneler vælger anderledes

Med en rutebaseret grænseflade afgør routingtabellen, hvad der kommer ind i tunnelen, og selektorerne kan være bevidst brede. Det er et legitimt design og ikke sjusk, og registreringen skal beskrive det som sådan. Skriv ruten ned, grænsefladen den peger på, og den firewallpolitik, der begrænser, hvilke tjenester der er tilgængelige. Beskyttelsesomfanget er bevidst bredt, og serviceomfanget står for indsnævringen.

At kopiere en politikbaseret skabelon over på en rutebaseret tunnel giver et dokument, der beskriver en mekanisme, som udrulningen ikke bruger. Den næste ingeniør leder så efter selektorer, der aldrig var ment at være der, og konkluderer, at tunnelen er forkert konfigureret, når den blot er dårligt dokumenteret.

Oversættelse hører i samme tabel

Når NAT præsenterer et andet område for modparten, registrer de oprindelige og de oversatte præfikser sammen. Noter det trin, hvor selektorer og adgangsregler matcher dem, fordi rækkefølgen afgør, om den fjerne side nogensinde ser den adresse, du skrev ned. En tabel med kun et af de to områder er værre end ingen tabel, fordi den ser komplet ud.

Det er den detalje, der brækker en fungerende tunnel efter en NAT-ændring: selektoren matcher stadig det oprindelige præfiks, modparten modtager nu et oversat, og dens returrute peger på en adresse, der ikke findes længere. Intet logger en fejl i det øjeblik, de to holder op med at stemme overens.

Privat DNS hører samme sted. Et navn, der opløses til en adresse, som er ubrugelig fra det relevante sted, er en dokumentationsfejl med en supportbillet vedhæftet, og den vil blive givet tunnelen skylden for.

Vedhæft servicekravet

Et beskyttet område er ikke en tilladelsesliste. Skriv ned, hvilke tjenester der skal være tilgængelige fra hvilken kilde, og hvem der ejer applikationen bag dem. De to felter besvarer forskellige spørgsmål, og at blande dem er måden, hvorpå en sikkerhedsgennemgang ender med at skændes om routing i stedet for adgang.

Navngiv derefter netværksadministratoren, der vedligeholder reglen. En selektorfortegnelse uden ejer bliver stille forældet, og forældet kan ikke skelnes fra forkert, når tunnelen brækker klokken to om morgenen. Ejeren er også den person, der kan bekræfte, at en ændring var bevidst.

Gør registreringen til en testplan

For hver påkrævet vej skal du vælge en repræsentativ kilde- og destinationsvært og notere den forventede rute, tjeneste og svar-gateway. Det gør dokumentet til en testplan i stedet for en beskrivelse. Læs den levende associering tilbage med kommandoen nedenfor, og sammenlign den med den forhandlede række, du skrev ned.

swanctl --list-sas

En skitse på fem linjer er normalt nok til at holde registreringen ærlig. Versionen nedenfor passer i en ændringsbillet uden afkortning:

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

Et ping kun til gatewayen er ikke accepttesten. Den udøver aldrig transitvejen, så den kan bestå, mens hver videresendt strøm fejler. Test fra en vært på den ene side til en tjeneste på den anden, og bekræft, at svaret ankommer gennem tunnelen. Hvis kun pinget består, har registreringen netop fundet det videresendelsesproblem, den blev skrevet for at forhindre. strongSwan-dokumentation om videresendelse forklarer, hvordan selektorer, ruter og videresendelse spiller sammen på en Linux-modpart.