Dos grups de clients, un servidor: on aplicar la política

Posar dos grups de clients en subxarxes diferents sembla aïllament, i no ho és. Les adreces descriuen d’on sembla que ve un paquet, mentre que el permís és una decisió que pren qui el reenvia. Aquesta pregunta la respon la configuració i no la màscara, així que decidiu quin component reenvia el trànsit entre iguals abans d’escriure cap regla.

Una subxarxa és una etiqueta, no una regla

Assignar un pool per grup us dona adreces llegibles i res més. Un client que accepta una ruta addicional ha guanyat abast, i l’abast no és autorització. El permís per parlar és a la decisió de reenviament, que pot viure al dimoni o al nucli segons com estigui configurat el servidor.

La propietat de l’adreça és el que fa que un prefix sigui utilitzable com a selector de grup. Cada identitat autenticada ha de correspondre a una adreça o un interval predictible, i aquesta correspondència falla tan bon punt diversos dispositius comparteixen una credencial i una assignació. Resoleu la identitat i la simultaneïtat abans de confiar en un prefix d’origen, perquè una política que endevina quina màquina truca autoritza la equivocada en el pitjor moment.

Trieu la via que transporta el trànsit entre iguals

Quan el dimoni reenvia paquets entre iguals dins del seu propi procés, aquests paquets no arriben mai al ganxo de reenviament de l’amfitrió, així que una regla del nucli no els pot veure. Desactiveu aquest reenviament intern i el nucli esdevé el punt de reenviament, on s’apliquen les regles de reenviament ordinàries.

# 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

Els canals de dades descarregats i els servidors gestionats pel producte publiquen els seus propis models d’aplicació, així que confirmeu quin feu servir en lloc de suposar el comportament de la comunitat. La fallada que val la pena evitar és una regla que sembla correcta en una revisió i que mai es consulta en temps d’execució.

Escriviu la matriu abans d’escriure regles

Una matriu curta és més fàcil de revisar que un conjunt de regles, i és el contracte que la implementació ha de complir: iguals del mateix grup permesos, iguals entre grups denegats, tots dos grups permesos cap a un servei compartit anomenat, tota la resta denegat. Escriviu aquestes quatre línies abans d’obrir un editor de tallafocs. Un revisor que no llegeix la sintaxi de les regles encara pot comprovar la matriu. Llavors la implementació només ha de coincidir amb les línies.

Mantingueu les tres classes de destinació separades mentre l’escriviu. Un servei a l’amfitrió VPN és entrada local, un altre client és trànsit entre iguals i una màquina darrere la passarel·la és una via de reenviament diferent. Una regla generosa pot concedir les tres per accident, i així és com una política de grup es converteix en una xarxa plana amb passos extra. Escriviu la classe al costat de cada fila perquè la intenció sobrevisqui a la propera edició.

Poseu les regles on sobreviuen

Afegiu les decisions al mateix lloc on es manté la resta del tallafocs, abans de qualsevol regla permissiva que altrament se les empassaria. L’ordre de les regles forma part de la política, i una regla correcta col·locada després d’una acceptació àmplia no fa complir res. Anoteu els números de regla abans i després del canvi. Una política que existeix en un editor però no al conjunt de regles en execució és un pla, no un control.

Decidiu què passa amb els fluxos que ja existeixen quan canvia la política, perquè una sessió oberta abans del canvi pot continuar després. Si un membre que se’n va ha de perdre l’accés immediatament, el conjunt de regles necessita una manera d’acabar aquest estat en lloc d’esperar que la connexió es tanqui sola.

Feu persistents les regles mitjançant el mecanisme que posseeix la resta del tallafocs, i registreu la matriu al costat. Una política no registrada es torna a derivar de la memòria durant el proper incident, normalment per algú que té pressa.

Demostreu-ho des de tots dos costats

Proveu l’abast dins del mateix grup, la fallada entre grups i el servei compartit des d’un client de cada grup. Una sola prova des d’un sol client demostra la meitat de la matriu, i la meitat que deixa fora és normalment la que està malament. Repetiu la direcció de denegació dues vegades, perquè una sessió en memòria cau pot amagar un error d’aplicació. Registreu quina parella heu provat perquè la propera persona no la repeteixi.

Repetiu la comprovació a IPv6 si el túnel el transporta, i manteniu l’autenticació normal d’aplicacions. Un prefix d’origen no és un compte, així que passar la política de xarxa no vol dir que un servei hagi de confiar en el sol·licitant.