Kva som må dokumenterast for eit VPN mellom nettstadar: selektorar og omfang

Seks månader etter at ein tunnel vart sett opp, sluttar eit nytt subnett å passe med policyen, og det einaste dokumentet på delinga seier kontor-VPN. Det er feilen ei selektoroversikt hindrar, og han er konkret: eit adressesett endra seg medan papira ikkje gjorde det. Å skrive oversikta rett tyder å vite kva av fleire adressesett du skildrar, og å føre opp det motparten faktisk handhevar, ikkje det du konfigurerte.

Konfigurert er ikkje forhandla

I ein policybasert IPsec-tunnel føreslår kvar side trafikkselektorar: kjelde- og målområde for barnassosiasjonen. Den svarande parten har lov til å snevre inn forslaget, så den installerte assosiasjonen kan dekkje mindre enn konfigurasjonen listar opp. Ei oversikt som kopierer konfigurasjonen skildrar ein intensjon, ikkje det gjeldande vernomfanget. Dei to glir frå kvarandre i stillheit, og ingenting på statussida til tunnelen peikar på det.

Hald på begge kolonnane, med datoen du observerte dei. Den konfigurerte selektoren er det du meinte; den forhandla er det kjernen handhevar akkurat no. Når dei er ulike, forklarer den skilnaden ein overraskande feil langt oftare enn ein rutefeil gjer.

Éin assosiasjon representerer heller ikkje kvart konfigurert par. Ein tunnel med fleire selektorkombinasjonar kan enda opp med fleire barnassosiasjonar, og ei oversikt som listar opp éin av dei er ei delvis inventarliste. List dei opp i staden for å oppsummere dei.

Rutebaserte tunnelar vel annleis

Med eit rutebasert grensesnitt avgjer rutetabellen kva som kjem inn i tunnelen, og selektorane kan vere medvite breie. Det er ei legitim utforming og ikkje slurv, og oversikta må skildre det som nettopp det. Skriv ned ruta, grensesnittet ho peikar på, og brannmurpolicyen som avgrensar kva tenester som er tilgjengelege. Vernomfanget er breitt med vilje, og tenesteomfanget gjer innsnevringa.

Å kopiere ein policybasert mal over på ein rutebasert tunnel gir eit dokument som skildrar ein mekanisme utrullinga ikkje brukar. Den neste ingeniøren leitar då etter selektorar som aldri var meint å vere der, og konkluderer med at tunnelen er feilkonfigurert når han berre er dårleg dokumentert.

Omsetjing høyrer heime i same tabell

Når NAT viser motparten eit anna område, før opp dei opphavlege og dei omsette prefiksa saman. Noter kva trinn selektorane og tilgangsreglane matchar dei i, fordi rekkjefølgja avgjer om den andre sida nokon gong ser adressa du skreiv ned. Ein tabell med berre eitt av dei to områda er verre enn ingen tabell, sidan han ser fullstendig ut.

Dette er detaljen som bryt ein fungerande tunnel etter ei NAT-endring: selektoren matchar framleis det opphavlege prefikset, motparten mottek no eit omsett eit, og returruta peikar på ei adresse som ikkje lenger finst. Ingenting loggar ein feil i det augneblunken dei sluttar å stemme overeins.

Privat DNS høyrer heime same stad. Eit namn som blir løyst til ei adresse som er ubrukeleg frå den aktuelle nettstaden, er ein dokumentasjonsfeil med ei støttebillett vedlagd, og han vil bli lagd på tunnelen.

Fest tenestekravet

Eit verna område er ikkje ei tillatingsliste. Skriv ned kva tenester som skal vere tilgjengelege frå kva kjelde, og kven som eig applikasjonen bak dei. Dei to felta svarar på ulike spørsmål, og å slå dei saman er korleis ein sikkerheitsgjennomgang endar med å krangle om ruting i staden for tilgang.

Namngi så nettverksadministratoren som vedlikeheld regelen. Ei selektoroversikt utan eigar blir sakte utdatert, og utdatert er umogeleg å skilje frå feil når tunnelen ryker klokka to om natta. Eigaren er også den som kan stadfeste at ei endring var tilsikta.

Gjer oversikta om til ein testplan

For kvar påkravd veg, vel ein representativ kjelde- og målvert og noter forventa rute, teneste og svarport. Det gjer dokumentet til ein testplan i staden for ei skildring. Les den aktive assosiasjonen tilbake med kommandoen nedanfor, og samanlikn han med den forhandla linja du skreiv ned.

swanctl --list-sas

Eit skjelett på fem linjer er vanlegvis nok til å halde oversikta ærleg. Versjonen nedanfor får plass i ein endringsbillett utan å bli avkorta:

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

Ping berre til porten er ikkje akseptansetesten. Han prøver aldri transittvegen, så han kan bestå medan kvar vidaresendt straum feilar. Test frå ein vert på den eine sida til ei teneste på den andre og stadfest at svaret kjem gjennom tunnelen. Viss berre ping består, har oversikta nettopp funne vidaresendingsproblemet ho vart skriven for å hindre. strongSwan-dokumentasjonen om vidaresending forklarer korleis selektorar, ruter og vidaresending samverkar på ein Linux-part.