To klientgrupper, én server: hvor politikken skal håndhæves
Subnetter mærker grupper; de isolerer dem ikke. Beslut, hvilken videresendelsesvej reglen tilhører, og skriv derefter den matrix, implementeringen skal håndhæve.
At placere to klientgrupper på forskellige subnetter ligner isolering, og det er det ikke. Adresser beskriver, hvor en pakke tilsyneladende kommer fra, mens tilladelse er en beslutning, der træffes af det, der videresender den. Det spørgsmål besvares af konfigurationen snarere end af masken, så beslut, hvilken komponent der videresender peer-trafik, før du skriver nogen regel.
Et subnet er en etiket, ikke en regel
At tildele én pulje pr. gruppe giver dig læsbare adresser og intet andet. En klient, der accepterer en ekstra rute, har fået rækkevidde, og rækkevidde er ikke autorisation. Tilladelsen til at tale ligger i videresendelsesbeslutningen, som kan leve i dæmonen eller i kernen afhængigt af, hvordan serveren er konfigureret.
Adresseejerskab er det, der gør et præfiks brugbart som gruppevælger. Hver autentificeret identitet skal knyttes til en forudsigelig adresse eller et interval, og den mapping fejler, så snart flere enheder deler én adgangsoplysning og én tildeling. Løs identitet og samtidighed, før du stoler på et kildebpræfiks, for en politik, der gætter på, hvilken maskine der ringer, autoriserer den forkerte på det værst tænkelige tidspunkt.
Vælg den vej, der bærer peer-trafik
Når dæmonen videresender peer-pakker inde i sin egen proces, når de pakker aldrig videresendelseskrogen på værten, så en kerneregel kan ikke se dem. Slå den interne videresendelse fra, og kernen bliver videresendelsespunktet, hvor almindelige videresendelsesregler gælder.
# 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
Aflastede datakanaler og produktstyrede servere offentliggør deres egne håndhævelsesmodeller, så bekræft, hvilken du kører, i stedet for at antage fællesskabets adfærd. Den fejl, der er værd at undgå, er en regel, der ser korrekt ud i en gennemgang og aldrig bliver konsulteret under kørsel.
Skriv matricen, før du skriver regler
En kort matrix er lettere at gennemgå end et regelsæt, og det er den kontrakt, implementeringen skal opfylde: peers i samme gruppe tillades, peers på tværs af grupper afvises, begge grupper tillades til én navngivet delt tjeneste, alt andet afvises. Skriv de fire linjer ned, før du åbner en firewall-editor. En gennemgåer, der ikke læser regelsyntaks, kan stadig kontrollere matricen. Derefter skal implementeringen bare matche linjerne.
| 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 destinationsklasser adskilt, mens du skriver den. En tjeneste på VPN-værten er lokalt input, en anden klient er peer-transit, og en maskine bag gatewayen er en anden videresendelsesvej. Én rundhåndet regel kan ved et uheld give alle tre, og det er sådan en gruppepolitik bliver til et fladt netværk med ekstra trin. Skriv klassen ved hver række, så hensigten overlever den næste redigering.
Sæt reglerne, hvor de overlever
Tilføj beslutningerne samme sted, hvor resten af firewallen vedligeholdes, foran enhver tilladende regel, der ellers ville sluge dem. Regelrækkefølge er en del af politikken, og en korrekt regel placeret efter en bred accept håndhæver intet som helst. Noter reglens numre før og efter ændringen. En politik, der findes i en editor men ikke i det kørende regelsæt, er en plan, ikke en kontrol.
Beslut, hvad der sker med flows, der allerede findes, når politikken ændres, for en session, der blev åbnet før ændringen, kan fortsætte bagefter. Hvis et medlem, der forlader, straks skal miste adgang, har regelsættet brug for en måde at afslutte den tilstand på i stedet for at vente på, at forbindelsen lukker af sig selv.
Gør reglerne varige via den mekanisme, der ejer resten af firewallen, og registrér matricen ved siden af dem. En uregistreret politik bliver udledt igen fra hukommelsen under den næste hændelse, normalt af en, der har travlt.
Bevis det fra begge sider
Test rækkevidde inden for samme gruppe, fejl på tværs af grupper og den delte tjeneste fra én klient i hver gruppe. En enkelt test fra en enkelt klient beviser halvdelen af matricen, og den halvdel, den udelader, er normalt den forkerte. Gentag afvisningsretningen to gange, fordi en cachet session kan skjule en håndhævelsesfejl. Noter, hvilket par du testede, så den næste person ikke gentager det.
Gentag kontrollen på IPv6, hvis tunnelen bærer det, og behold almindelig applikationsautentificering. Et kildebpræfiks er ikke en konto, så at bestå netværkspolitikken betyder ikke, at en tjeneste bør stole på den, der ringer.