Hva som må dokumenteres for et VPN mellom nettsteder: selektorer og omfang

Seks måneder etter at en tunnel ble satt opp, slutter et nytt subnett å passe med policyen, og det eneste dokumentet på delingen sier kontor-VPN. Det er feilen en selektoroversikt forhindrer, og den er konkret: et adressesett endret seg mens papirene ikke gjorde det. Å skrive oversikten riktig betyr å vite hvilket av flere adressesett du beskriver, og å føre opp det motparten faktisk håndhever, ikke det du konfigurerte.

Konfigurert er ikke forhandlet

I en policybasert IPsec-tunnel foreslår hver side trafikkselektorer: kilde- og målområder for barnassosiasjonen. Den svarrende parten har lov til å snevre inn forslaget, så den installerte assosiasjonen kan dekke mindre enn konfigurasjonen lister opp. En oversikt som kopierer konfigurasjonen beskriver en intensjon, ikke det gjeldende beskyttelsesomfanget. De to glir fra hverandre i stillhet, og ingenting på tunnelens statusside peker på det.

Behold begge kolonnene, med datoen du observerte dem. Den konfigurerte selektoren er det du mente; den forhandlede er det kjernen håndhever akkurat nå. Når de er ulike, forklarer den forskjellen en overraskende feil langt oftere enn en rutingfeil gjør.

Én assosiasjon representerer heller ikke hvert konfigurerte par. En tunnel med flere selektorkombinasjoner kan ende opp med flere barnassosiasjoner, og en oversikt som lister opp én av dem er en delvis inventarliste. List dem opp i stedet for å oppsummere dem.

Rutebaserte tunneler velger annerledes

Med et rutebasert grensesnitt avgjør rutetabellen hva som kommer inn i tunnelen, og selektorene kan være bevisst brede. Det er en legitim utforming og ikke slurv, og oversikten må beskrive det som nettopp det. Skriv ned ruten, grensesnittet den peker på, og brannmurpolicyen som begrenser hvilke tjenester som er tilgjengelige. Beskyttelsesomfanget er bredt med vilje, og tjenesteomfanget gjør innsnevringen.

Å kopiere en policybasert mal over på en rutebasert tunnel gir et dokument som beskriver en mekanisme utrullingen ikke bruker. Den neste ingeniøren leter da etter selektorer som aldri var ment å være der, og konkluderer med at tunnelen er feilkonfigurert når den bare er dårlig dokumentert.

Oversetting hører hjemme i samme tabell

Når NAT viser motparten et annet område, før opp de opprinnelige og de oversatte prefiksene sammen. Noter hvilket trinn selektorene og tilgangsreglene matcher dem i, fordi rekkefølgen avgjør om den andre siden noen gang ser adressen du skrev ned. En tabell med bare ett av de to områdene er verre enn ingen tabell, siden den ser fullstendig ut.

Dette er detaljen som bryter en fungerende tunnel etter en NAT-endring: selektoren matcher fortsatt det opprinnelige prefikset, motparten mottar nå et oversatt et, og returruten peker på en adresse som ikke lenger finnes. Ingenting logger en feil i det øyeblikket de slutter å stemme overens.

Privat DNS hører hjemme samme sted. Et navn som løses til en adresse som er ubrukelig fra det aktuelle nettstedet, er en dokumentasjonsfeil med en supportbillett vedlagt, og den vil bli lagt på tunnelen.

Fest tjenestekravet

Et beskyttet område er ikke en tillatelsesliste. Skriv ned hvilke tjenester som skal være tilgjengelige fra hvilken kilde, og hvem som eier applikasjonen bak dem. De to feltene svarer på ulike spørsmål, og å slå dem sammen er hvordan en sikkerhetsgjennomgang ender med å krangle om ruting i stedet for tilgang.

Navngi så nettverksadministratoren som vedlikeholder regelen. En selektoroversikt uten eier blir sakte utdatert, og utdatert er umulig å skille fra feil når tunnelen ryker klokken to om natten. Eieren er også den som kan bekrefte at en endring var tilsiktet.

Gjør oversikten om til en testplan

For hver påkrevde vei, velg en representativ kilde- og målvert og noter forventet rute, tjeneste og svarport. Det gjør dokumentet til en testplan i stedet for en beskrivelse. Les den aktive assosiasjonen tilbake med kommandoen nedenfor, og sammenlign den med den forhandlede linjen du skrev ned.

swanctl --list-sas

Et skjelett på fem linjer er vanligvis nok til å holde oversikten ærlig. Versjonen nedenfor får plass i en endringsbillett uten å bli avkortet:

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 bare til porten er ikke akseptansetesten. Den prøver aldri transittveien, så den kan bestå mens hver videresendte strøm feiler. Test fra en vert på den ene siden til en tjeneste på den andre og bekreft at svaret kommer gjennom tunnelen. Hvis bare ping består, har oversikten nettopp funnet videresendingsproblemet den ble skrevet for å forhindre. strongSwan-dokumentasjonen om videresending forklarer hvordan selektorer, ruter og videresending samvirker på en Linux-part.