Per què una regla de bloqueig de client OpenVPN no arriba mai a FORWARD

Dos clients del mateix servidor OpenVPN poden arribar-se l'un a l'altre encara que hàgiu afegit una regla DROP per al seu pool. La regla és a la cadena FORWARD, el trànsit flueix clarament i el comptador d'aquella regla continua a zero. La conclusió natural és que el tallafoc està espatllat. Més sovint, el paquet no ha entrat mai a la cadena.

Hi ha dos camins que un paquet d'igual pot seguir per un servidor OpenVPN, i els decideix la configuració, no el tallafoc. Saber quin camí s'usa us diu si una regla de l'amfitrió és fins i tot al lloc correcte.

Dos camins que pot seguir un paquet d'igual

Amb l'opció de reenviament intern desactivada, un paquet del client A arriba a la interfície del túnel amb una destinació dins de l'adreça assignada al client B. La taula d'encaminament del servidor el torna a enviar per la mateixa interfície del túnel, perquè el servidor té la ruta cap a l'adreça de B. És un flux d'entrada i sortida per l'amfitrió, i el camí de reenviament IPv4 l'avalua.

Amb l'opció de reenviament intern activada, el procés del servidor emparella el paquet amb un client connectat i l'escriu de tornada a aquell mateix client. El paquet es gestiona dins del dimoni i no torna mai a entrar al dispositiu del túnel, així que el camí de reenviament de l'amfitrió se salta del tot. El manual d'OpenVPN 2.6 descriu aquesta opció com a reenviament intern de client a client, i és exactament per això que una regla del tallafoc de l'amfitrió no la pot veure.

Existeix una tercera variant en desplegaments que descarreguen el canal de dades a un mòdul del nucli. La decisió de reenviament i el xifrat surten de l'espai d'usuari, i si netfilter observa el flux depèn de com estigui construït el camí de descàrrega. No assumiu mai que un conjunt de regles antic es comporta en un servidor descarregat igual que en un d'espai d'usuari. Confirmeu el mode a partir de la configuració en execució, no de la versió del paquet.

Quan el comptador no es mou mai

Un comptador a zero vol dir que el paquet no va coincidir amb aquella regla en aquell punt, i hi ha diversos motius. El primer és el desviament anterior: el trànsit no va arribar mai a la cadena. El segon és una discrepància en la interfície, la direcció, l'origen o la destinació, cosa habitual quan el pool s'ha renumerat i la regla encara anomena el prefix antic.

El tercer és la posició. Una regla anterior a la cadena pot acceptar el flux abans que s'avaluï el vostre DROP, i una regla posterior pot ser la que realment decideix el resultat. Llegiu la cadena en ordre amb els comptadors visibles i després comproveu quin comptador augmenta quan repetiu la prova.

Feu un intercanvi controlat entre dos clients les adreces reals dels quals hàgiu confirmat a partir del mateix estat del servidor, no d'un arrendament que recordeu. Si el comptador rellevant encara no es mou, sospiteu del camí abans de reescriure la coincidència. Si es mou però la connexió encara té èxit, el descart s'està sobreescrivint més endavant i el problema és l'ordre. Aquesta resposta decideix si la reparació és un canvi de regla o un canvi de topologia, així que obteniu-la abans d'editar res.

Triar una frontera que pugui filtrar

Si la política ha de viure al tallafoc de l'amfitrió, poseu el trànsit on el tallafoc el pugui veure. Desactivar el reenviament intern és la manera suportada de fer que el trànsit d'iguals travessi la interfície del túnel i el camí de reenviament, a costa d'enviar cada paquet d'igual per la pila de l'amfitrió.

Després emparelleu el flux amb precisió. El trànsit arriba a la interfície del túnel i en surt per la interfície del túnel, en tots dos sentits, així que les regles que només consideren la interfície física no coincidiran. Les regles basades en adreces necessiten el pool actual i han de tenir en compte el sentit de retorn tant com el d'anada.

Molts desplegaments es serveixen millor filtrant a nivell de client o de grup, on la identitat és coneguda i la política segueix l'usuari en lloc d'una adreça que canvia en reconectar. És un mecanisme diferent del d'una cadena de l'amfitrió, i els dos no s'han de barrejar sense un motiu clar.

No porteu un conjunt de regles d'una topologia antiga a través d'una migració sense canvis. Els pools d'adreces, els noms d'interfície i els modes de reenviament afecten tots si una regla coincideix, i una regla copiada que abans funcionava és el tipus d'evidència més enganyós. Comenceu pel flux que voleu permetre i escriviu la regla que hi coincideixi.

Provar l'aïllament en lloc de confiar en una regla

Proveu el cas prohibit i el cas permès en la mateixa execució. Inicieu una connexió nova d'un client a l'altre i confirmeu que falla, després confirmeu que una connexió que hauria de permetre's encara funciona. Si només es prova el primer, un tallafoc que bloqueja tot sembla un èxit.

Repetiu després de recarregar la configuració del servidor i després que un client es reconnecti, perquè el reenviament intern i les assignacions de pool són estat d'execució. Comproveu els comptadors en tots dos sentits, ja que una regla que coincideix amb un sentit i no amb la resposta produeix un aïllament parcial difícil de notar en una prova ràpida.

L'aïllament és el resultat observat a la frontera que realment porta el flux. Una regla DROP en algun lloc de l'amfitrió no és evidència; una connexió fallida més un comptador mogut a la regla que la va causar sí que ho és.