Hvordan begrense tilgangen mellom to VPN-tilkoblede kontorer

En tunnel mellom lokaliteter svarer på ett spørsmål, om de to kontorene kan utveksle pakker, og lar det viktige stå åpent: hvilken filialenhet som kan nå hvilken sentral tjeneste. Å behandle tunnelen som gjensidig tillit er måten en gjestelaptop havner på samme vei som finansserveren. Løsningen er ikke en bedre tunnel, men en uttrykkelig tillatelsesliste som håndheves etter dekryptering. Denne veiledningen tar listen fra definisjon til en bevist avvisning.

Arbeid i denne rekkefølgen, og ikke utvid tunnelruten før policytiltakene nedenfor består.

Skriv matrisen før du rører gatewayen

En nyttig rad navngir tre ting: en kildegruppe, en målvert eller tjenestenettverk, og protokollen og porten som applikasjonen faktisk bruker. Filialen og datasenteret er ikke oppføringer. Privat DNS og autentiseringstjenester fortjener egne rader bare når applikasjonen ikke kan fungere uten dem.

Grupper kilder etter rolle og ikke etter subnett-bekvemmelighet: ansatte, gjester, administrasjon. Når alle tre deler ett flatt LAN, kan gatewayen ikke skille dem på nettverkslaget, så identitetskontroller eller segmentering må komme først. Deretter setter du matrisen på skrift med en eier og en revisjonsdato på hver rad.

Håndhev der pakkene dekrypteres

Reglene som tillater IKE og ESP bygger bare den ytre tunnelen. Den indre trafikken kommer i klartekst på tunnelgrensesnittet, og det er der tillatelseslisten hører hjemme: en videresendingskjede på enheten som dekrypterer, standarddropp, én regel per matriserad. På Linux-gatewayer betyr det at videresending er slått på og filterregler ligger på tunnelenheten, ikke på den fysiske uplinken, slik strongSwans veiledning for videresending forklarer.

Trafikkvelgere er en rutebeslutning, ikke en autorisasjonsbeslutning. En bred velger som dekker begge subnett kan være riktig for ruting mens brannmuren fortsatt bare tillater TCP 443 til én vert. Velgeren forhandles for tunnelen og beskriver hva som kan komme inn i den, ikke hva en gitt enhet kan bruke. Utvid aldri en brannmurregel fordi velgeren er bred.

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 overlappende subnett endrer reglene

Når filialens gateway oversetter hver vert til én adresse før tunnelen, faller hver kildebaserte rad sammen i den ene adressen. Enten slutter du å oversette tunneltrafikk, eller du godtar at regler må bygge på noe annet, for eksempel den opprinnelige kildeadressen som ble registrert før oversettelsen. Den fjerne enden har samme problem, fordi målverten ser adressen etter NAT og ikke den opprinnelige.

Overlappende områder er den andre fellen. To kontorer som begge bruker 192.168.1.0/24 kan ikke beskrives i én policytabell uten å kartlegge én side, og en kartlegging er ikke en erstatning for adressering som ikke kolliderer. Rett opp planen før du skriver regler du senere må nøste opp.

Bevis en avvisning, ikke bare en suksess

Å teste bare den tillatte applikasjonen beviser svært lite, fordi en ettergivende regel et sted lenger opp gir samme resultat.

Fra en vanlig filialenhet, nå den tiltenkte tjenesten og bekreft at hele sesjonen virker. Prøv deretter et mål som må forbli lukket, for eksempel en administrativ port på en server filialen ikke har noe med å gjøre, og les telleren eller loggoppføringen som droppet den. Å slå av regelsettet for å sjekke om det virker gjør testen ugyldig og lar gatewayen stå åpen mens du ser på.

Hold listen levende

Applikasjoner flytter på seg, og en regel som overlever applikasjonen sin, blir et hull ingen eier. Fest revisjonsdatoen til raden, og endre velgerens omfang og brannmurregelen i samme vedlikeholdstrinn når en tjeneste bytter adresse.

Begrensninger på vertsnivå betyr fortsatt noe bak tunnelen: serverens egen brannmur bør bare godta filialens område for tjenesten den publiserer. To lag som er enige er lettere å revidere enn ett lag som stoles fullt ut.