Korleis avgrense tilgangen mellom to VPN-tilkopla kontor

Ein tunnel mellom lokalitetar svarar på eitt spørsmål, om dei to kontora kan utveksle pakkar, og lèt det viktige stå ope: kva filialeining som kan nå kva sentral teneste. Å handsame tunnelen som gjensidig tillit er måten ein gjestelaptop hamnar på same veg som finansserveren. Løysinga er ikkje ein betre tunnel, men ei uttrykkeleg løyveliste som vert handheva etter dekrypteringa. Denne rettleiinga tek lista frå definisjon til eit prova avslag.

Arbeid i denne rekkjefølgja, og ikkje utvid tunnelruta før policytiltaka nedanfor går gjennom.

Skriv matrisa før du rører gatewayen

Ei nyttig rad nemner tre ting: ei kjeldegruppe, ein målvert eller eit tenestenettverk, og protokollen og porten som applikasjonen faktisk brukar. Filialen og datasenteret er ikkje oppføringar. Privat DNS og autentiseringstenester fortener eigne rader berre når applikasjonen ikkje kan fungere utan dei.

Grupper kjelder etter rolle og ikkje etter subnett-bekvemmelegheit: tilsette, gjester, administrasjon. Når alle tre deler eitt flatt LAN, kan gatewayen ikkje skilje dei på nettverkslaget, så identitetskontrollar eller segmentering må kome først. Deretter set du matrisa på skrift med ein eigar og ein revisjonsdato på kvar rad.

Handhev der pakkane vert dekrypterte

Reglane som tillèt IKE og ESP byggjer berre den ytre tunnelen. Den indre trafikken kjem i klartekst på tunnelgrensesnittet, og det er der løyvelista høyrer heime: ei vidaresendingskjede på eininga som dekrypterer, standarddropp, éin regel per matriserad. På Linux-gatewayar tyder det at vidaresending er slått på og filterreglar ligg på tunneleininga, ikkje på den fysiske uplinken, slik rettleiinga til strongSwan om vidaresending forklarer.

Trafikkveljarar er eit rutevedtak, ikkje eit autorisasjonsvedtak. Ein brei veljar som dekkjer begge subnett kan vere riktig for ruting medan brannmuren framleis berre tillèt TCP 443 til éin vert. Veljaren vert forhandla for tunnelen og skildrar kva som kan kome inn i han, ikkje kva ei gjeven eining kan bruke. Utvid aldri ein brannmurregel fordi veljaren er brei.

iptables -A FORWARD -i tun0 -s 10.20.0.0/24 -d 10.10.5.10 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i tun0 -j DROP

NAT og overlappande subnett endrar reglane

Når gatewayen i filialen omset kvar vert til éin adresse før tunnelen, fell kvar kjeldebaserte rad saman i den eine adressa. Anten sluttar du å omsetje tunneltrafikk, eller du godtek at reglar må byggje på noko anna, til dømes den opphavlege kjeldeadressa som vart registrert før omsetjinga. Den fjerne enden har same problemet, fordi målverten ser adressa etter NAT og ikkje den opphavlege.

Overlappande område er den andre fella. To kontor som begge brukar 192.168.1.0/24 kan ikkje skildrast i éin policytabell utan å kartleggje éi side, og ein kartleggjing er ikkje ei erstatning for adressering som ikkje kolliderer. Rett opp planen før du skriv reglar du seinare må nøste opp.

Prov eit avslag, ikkje berre ein suksess

Å teste berre den tillatne applikasjonen provar svært lite, fordi ein ettergjevande regel ein stad lenger opp gjev same resultat.

Frå ei vanleg filialeining, nå den tiltenkte tenesta og stadfest at heile sesjonen verkar. Prøv deretter eit mål som må halde seg lukka, til dømes ein administrativ port på ein server filialen ikkje har noko med å gjere, og les teljaren eller loggoppføringa som slapp han. Å slå av regelsettet for å sjekke om det verkar gjer testen ugyldig og lèt gatewayen stå open medan du ser på.

Hald lista levande

Applikasjonar flyttar på seg, og ein regel som overlever applikasjonen sin, vert eit hol ingen eig. Fest revisjonsdatoen til rada, og endre omfanget til veljaren og brannmurregelen i same vedlikehaldstrinn når ei teneste byter adresse.

Avgrensningar på vertsnivå betyr framleis noko bak tunnelen: brannmuren til serveren sjølv bør berre godta området til filialen for tenesta han publiserer. To lag som er samde er lettare å revidere enn eitt lag som vert stolt heilt på.