Twee klantgroepen, één server: waar het beleid wordt afgedwongen

Twee klantgroepen op verschillende subnetten zetten lijkt op isolatie, en dat is het niet. Adressen beschrijven waar een pakket vandaan lijkt te komen, terwijl toestemming een beslissing is van wat het doorstuurt. Die vraag wordt door configuratie beantwoord en niet door het masker, dus bepaal welke component peerverkeer doorstuurt voordat je een regel schrijft.

Een subnet is een label, geen regel

Eén pool per groep toewijzen geeft leesbare adressen en niets anders. Een client die een extra route accepteert, heeft bereikbaarheid gekregen, en bereikbaarheid is geen autorisatie. De toestemming om te praten zit in de doorstuur beslissing, die in de daemon of in de kernel kan leven, afhankelijk van hoe de server is geconfigureerd.

Adresseigendom is wat een prefix bruikbaar maakt als groepsselector. Elke geauthenticeerde identiteit moet aan een voorspelbaar adres of bereik worden gekoppeld, en die koppeling faalt zodra meerdere apparaten één inloggegeven en één toewijzing delen. Los identiteit en gelijktijdigheid op voordat je op een bronprefix vertrouwt, want een beleid dat raadt welke machine belt, autoriseert de verkeerde op het slechtste moment.

Kies het pad dat peerverkeer draagt

Wanneer de daemon peerpakketten binnen zijn eigen proces doorstuurt, bereiken die pakketten nooit de doorstuurhaak van de host, dus een kernelregel kan ze niet zien. Schakel die interne doorsturing uit en de kernel wordt het doorstuurpunt, waar gewone doorstuurregels gelden.

# 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

Afgehandelde datakanalen en door het product beheerde servers publiceren hun eigen handhavingsmodellen, dus bevestig welke je draait in plaats van het gedrag van de gemeenschap aan te nemen. De fout die het waard is te vermijden is een regel die er in een beoordeling correct uitziet en nooit tijdens runtime wordt geraadpleegd.

Schrijf de matrix voordat je regels schrijft

Een korte matrix is makkelijker te beoordelen dan een regelset, en het is het contract waaraan de implementatie moet voldoen: peers in dezelfde groep toegestaan, peers tussen groepen geweigerd, beide groepen toegestaan naar één genoemde gedeelde dienst, al het andere geweigerd. Schrijf die vier regels op voordat je een firewall-editor opent. Een beoordelaar die geen regelsyntaxis leest, kan de matrix alsnog controleren. De implementatie hoeft dan alleen bij de regels te passen.

Houd de drie bestemmingsklassen uit elkaar terwijl je het schrijft. Een dienst op de VPN-host is lokale invoer, een andere client is peertransit, en een machine achter de gateway is een ander doorstuurpad. Eén royale regel kan alle drie per ongeluk toekennen, en zo verandert een groepsbeleid in een plat netwerk met extra stappen. Schrijf de klasse naast elke rij zodat de bedoeling de volgende bewerking overleeft.

Plaats de regels waar ze overleven

Voeg de beslissingen toe op dezelfde plek waar de rest van de firewall wordt onderhouden, vóór elke toestemmende regel die ze anders zou opslokken. Regelvolgorde is deel van het beleid, en een correcte regel na een brede acceptatie dwingt niets af. Noteer de regelnummers voor en na de wijziging. Een beleid dat in een editor bestaat maar niet in de draaiende regelset, is een plan, geen controle.

Bepaal wat er gebeurt met stromen die al bestaan wanneer het beleid verandert, want een sessie die vóór de wijziging is geopend, kan daarna doorlopen. Als een vertrekkend lid onmiddellijk toegang moet verliezen, heeft de regelset een manier nodig om die toestand te beëindigen in plaats van te wachten tot de verbinding zelf sluit.

Maak de regels persistent via het mechanisme dat de rest van de firewall bezit, en leg de matrix ernaast vast. Een niet-vastgelegd beleid wordt tijdens het volgende incident opnieuw uit het geheugen afgeleid, meestal door iemand met haast.

Bewijs het van beide kanten

Test bereikbaarheid binnen dezelfde groep, falen tussen groepen en de gedeelde dienst vanaf één client in elke groep. Een enkele test vanaf een enkele client bewijst de helft van de matrix, en de helft die hij weglaat is meestal de verkeerde. Herhaal de weigeringsrichting twee keer, omdat een gecachte sessie een handhavingsfout kan verbergen. Noteer welk paar je hebt getest zodat de volgende persoon het niet herhaalt.

Herhaal de controle op IPv6 als de tunnel dat draagt, en houd gewone applicatieauthenticatie in stand. Een bronprefix is geen account, dus het doorstaan van het netwerkbeleid betekent niet dat een dienst de beller moet vertrouwen.