Com bloquejar la sortida de Linux perquè no s'escoli res quan cau la VPN

Imagineu una caixa multimèdia en un enllaç domèstic que només ha d'arribar a internet a través d'un túnel. Quan el túnel cau, l'aplicació hauria d'aturar-se en lloc de continuar silenciosament per la interfície física. Aconseguir aquest comportament és un problema de tallafocs i no d'encaminament, i la distinció importa perquè una ruta es pot substituir reiniciant el dimoni, mentre que un filtre es queda on l'heu posat. A continuació veureu com decideix realment el camí del paquet i després com limitar les excepcions que mantenen el túnel reconnectant.

La sortida local és un ganxo diferent del reenviament

Un paquet que surt d'una aplicació de la màquina travessa el ganxo de sortida; un paquet que la màquina encamina per a un altre amfitrió travessa el reenviament. Una política que només esmenta forward restringeix el segon i deixa el primer completament obert, i per això tants bloquejos de sortida semblen correctes i no fan res. L'aparellament d'interfície pertany a la mateixa regla: oifname "tun0" accept deixa passar el trànsit que ja s'ha encaminat pel túnel. Encaminament i filtratge també continuen sent decisions separades, així que una ruta d'enllaç pot existir mentre el filtre rebutja el paquet. Aquesta separació és el mecanisme en què confieu.

Una passarel·la que reenvia per a altres dispositius necessita tots dos ganxos. Bloquejar només la sortida protegeix la màquina i deixa cada client aigües avall lliure de filtrar.

Escriviu la llista d'excepcions de l'extrem cap enfora

Comenceu per l'extrem del túnel: una adreça de destinació o un conjunt petit aprovat, el protocol de transport i el port de destinació, per exemple udp dport 1194 ip daddr 203.0.113.7 accept. Si el client resol un nom d'amfitrió, l'intercanvi DNS d'arrencada necessita la seva pròpia regla limitada al resolutor i al port 53, no un permís general a l'adreça d'aquell resolutor. Cada excepció hauria de dir el motiu pel qual existeix. Un permís per a tot el trànsit UDP cap al port de la VPN cobreix molt més que el servei autenticat únic que teníeu al cap.

La resolució d'arrencada és on solen podrir-se els bloquejos. Un conjunt d'adreces que s'actualitza amb un temporitzador necessita un comportament definit quan l'actualització falla, i aquest comportament no pot ser obrir l'enllaç fins que funcioni. Actualitzeu pel túnel mentre el túnel està aixecat, i altrament torneu a l'últim extrem bo conegut.

L'administració local necessita el mateix tracte. Una subxarxa de gestió no és fiable només perquè les seves adreces siguin privades, i una regla que hi confia convida un segon camí al voltant del bloqueig.

Aparellar la interfície no demostra un túnel sa

Les regles que accepten tot el que surt de tun0 pressuposen que un paquet en aquesta interfície ve del túnel. Els noms d'interfície es recreen, i un nom no és una identitat criptogràfica. El parell també pot haver desaparegut mentre la interfície continua aixecada, cosa que converteix la regla en una no-operació molt convincent.

El seguiment de connexions afegeix una trampa relacionada. Una regla àmplia de connexions establertes reprodueix el permís que un flux va obtenir abans, de manera que una sessió iniciada abans que caigués el túnel continua funcionant després. Restringiu l'acceptació amb estat a les interfícies i adreces que realment voleu, o heu construït un bloqueig que s'obre sol. Les regles d'entrada i de sortida també responen preguntes diferents, i endurir una mentre ignoreu l'altra deixa la màquina accessible en la direcció que no heu considerat.

Què sobreviu a una caiguda del dimoni

Un filtre instal·lat per un script que s'executa després que el túnel pugi desapareix amb el túnel, just en el moment en què calia. Carregueu el bloqueig a l'arrencada i deixeu que el dimoni només gestioni les seves excepcions.

Suprimir la ruta per defecte tampoc no és un substitut. La ruta és estat que el dimoni posseeix i reescriu, i eliminar-la pot treure el camí necessari per reconnectar. IPv6 necessita el seu propi pla, perquè el descobriment de veïns i els anuncis de router són serveis d'enllaç que han de continuar funcionant mentre el trànsit ordinari està bloquejat. DHCP pertany a la mateixa categoria. Anoteu aquestes coses com a excepcions amb un propòsit, en lloc de descobrir-les més tard com a caigudes.

Camí de recuperació abans del desplegament

Proveu el bloqueig tal com fallarà: arrencar sense túnel, matar el dimoni, canviar l'extrem i reconnectar. Cada cas hauria d'aturar les aplicacions i deixar el canal de recuperació funcionant. Feu-ho des d'una consola, perquè un shell remot és la sessió que més probablement quedarà bloquejada per la vostra pròpia regla.

Després comproveu què pot assolir encara una aplicació corrent, amb una destinació innòcua i una petició que pugueu verificar. El resultat que voleu és un refús a l'enllaç i un èxit pel túnel, no un temps d'espera ambigu que podria significar qualsevol de les dues coses. Manteniu el conjunt de regles sota el mateix propietari que la resta del tallafocs, en lloc de substituir tota la taula des d'un script de shell. Una política en què cada permís pot justificar-se val més que un conjunt llarg de regles que ningú no pot explicar.