To klientgrupper, én server: hvor politikken skal håndheves
Subnett merker grupper; de isolerer dem ikke. Bestem hvilken videresendingsbane som eier regelen, og skriv deretter matrisen implementasjonen må håndheve.
Å plassere to klientgrupper på forskjellige subnett ser ut som isolasjon, og er det ikke. Adresser beskriver hvor en pakke tilsynelatende kommer fra, mens tillatelse er en beslutning tatt av det som videresender den. Det spørsmålet besvares av konfigurasjonen og ikke av masken, så bestem hvilken komponent som videresender peer-trafikk før du skriver noen regel.
Et subnett er en etikett, ikke en regel
Å tildele én pool per gruppe gir deg lesbare adresser og ingenting annet. En klient som godtar en ekstra rute har fått rekkevidde, og rekkevidde er ikke autorisasjon. Tillatelsen til å snakke ligger i videresendingsbeslutningen, som kan leve i daemonen eller i kjernen avhengig av hvordan serveren er konfigurert.
Adresseierskap er det som gjør et prefiks brukbart som gruppevelger. Hver autentiserte identitet må knyttes til en forutsigbar adresse eller et område, og den koblingen feiler så snart flere enheter deler én påloggingsinformasjon og én tildeling. Løs identitet og samtidighet før du stoler på et kildebprefiks, for en politikk som gjetter hvilken maskin som ringer, autoriserer den gale i det verst tenkelige øyeblikket.
Velg banen som bærer peer-trafikk
Når daemonen videresender peer-pakker inne i sin egen prosess, når disse pakkene aldri videresendingskroken på verten, så en kjerneregel kan ikke se dem. Slå av den interne videresendingen, og kjernen blir videresendingspunktet, der vanlige videresendingsregler gjelder.
# peer forwarding inside the daemon: enforce with per-group policy instead of FORWARD rules
client-to-client
# kernel forwarding path: remove the line above, then filter in the forward chain
Avlastede datakanaler og produktstyrte servere publiserer egne håndhevelsesmodeller, så bekreft hvilken du kjører i stedet for å anta fellesskapets atferd. Feilen det er verdt å unngå er en regel som ser riktig ut i en gjennomgang og aldri blir konsultert under kjøring.
Skriv matrisen før du skriver regler
En kort matrise er lettere å gjennomgå enn et regelsett, og det er kontrakten implementasjonen må oppfylle: peer i samme gruppe tillatt, peer på tvers av grupper avvist, begge grupper tillatt til én navngitt delt tjeneste, alt annet avvist. Skriv ned de fire linjene før du åpner en brannmur-editor. En gjennomgåer som ikke leser regel-syntaks kan likevel kontrollere matrisen. Deretter må implementasjonen bare samsvare med linjene.
| Source | Destination | Decision |
|---|---|---|
| Group A address | Another Group A address | Allow |
| Group A address | A Group B address | Deny |
| Either group | The shared internal service | Allow |
| Either group | Anything not listed | Deny |
Hold de tre destinasjonsklassene fra hverandre mens du skriver den. En tjeneste på VPN-verten er lokal inngang, en annen klient er peer-transitt, og en maskin bak gatewayen er en annen videresendingsbane. Én raus regel kan ved uhell gi alle tre, og det er slik en gruppepolitikk blir et flatt nettverk med ekstra trinn. Skriv klassen ved hver rad slik at intensjonen overlever neste redigering.
Sett reglene der de overlever
Legg til beslutningene på samme sted der resten av brannmuren vedlikeholdes, foran enhver tillatende regel som ellers ville svelge dem. Regelrekkefølge er en del av politikken, og en korrekt regel plassert etter en bred aksept håndhever ingenting. Noter reglenes numre før og etter endringen. En politikk som finnes i en editor men ikke i det kjørende regelsettet, er en plan, ikke en kontroll.
Bestem hva som skjer med strømmer som allerede finnes når politikken endres, for en sesjon som ble åpnet før endringen kan fortsette etterpå. Hvis et medlem som forlater må miste tilgang umiddelbart, trenger regelsettet en måte å avslutte den tilstanden på i stedet for å vente på at tilkoblingen lukker seg selv.
Gjør reglene varige gjennom mekanismen som eier resten av brannmuren, og registrer matrisen ved siden av. En uregistrert politikk blir utledet på nytt fra hukommelsen under neste hendelse, vanligvis av noen som har det travelt.
Bevis det fra begge sider
Test rekkevidde innenfor samme gruppe, feil på tvers av grupper og den delte tjenesten fra én klient i hver gruppe. Én test fra én klient beviser halve matrisen, og halvdelen den utelater er vanligvis den gale. Gjenta avvisningsretningen to ganger, fordi en bufret sesjon kan skjule en håndhevelsesfeil. Noter hvilket par du testet, slik at neste person ikke gjentar det.
Gjenta kontrollen på IPv6 hvis tunnelen bærer det, og behold vanlig applikasjonsautentisering. Et kildebprefiks er ikke en konto, så å bestå nettverkspolitikken betyr ikke at en tjeneste bør stole på den som ringer.