Per què una porta de tallafoc lligada a l'estat de la VPN no és una regla de ping només pel túnel

Imagineu una regla de tallafoc que activa l'ICMP echo per a l'adreça pública del servidor sempre que hi ha un perfil de VPN connectat. Es llegeix com «ping només pel túnel», i aquesta lectura és incorrecta d'una manera que importa. La regla no restringeix qui pot arribar a l'amfitrió; canvia què respon la interfície pública mentre una altra connexió és activa. Són dues polítiques diferents, i una d'elles amplia l'exposició sense fer soroll.

La regla que creieu haver escrit

El requisit previst sol ser estret: el sistema de monitoratge, o l'únic administrador de la VPN, ha de poder confirmar que el servidor és viu. Escrit com una frase, sona com un control d'accés al túnel. Escrit com un objecte de tallafoc, es converteix en una condició al perfil públic, perquè és allà on arriba la sol·licitud echo.

Quan la condició és un estat de connexió i no una adreça d'origen, el conjunt de remitents permesos ja no és el conjunt d'iguales de la VPN. Qualsevol que pugui arribar a l'adreça pública pot enviar una sol·licitud echo mentre la porta és oberta. El túnel no es va convertir en el camí; el túnel es va convertir en l'interruptor.

Qui promou aquesta idea normalment no menteix sobre l'efecte que volia. Necessitava una comprovació que només respongués quan l'enllaç fos sa, i la salut de l'enllaç era més fàcil d'observar a través de la VPN. L'error és tractar un senyal de disponibilitat com una decisió d'accés i després automatitzar-ho.

Què controla realment la porta

Aquest disseny fusiona dues coses independents, i separar-les és la major part de la correcció. La primera és l'abast: quina adreça local, quines adreces remotes, quin protocol i quin tipus d'ICMP. La segona és la condició: si l'objecte de regla està habilitat en aquest moment. L'abast és el que un tallafoc avalua per paquet; la condició és el que un script escriu al magatzem de polítiques, i tots dos es reconcilien amb rellotges completament diferents.

Si el requisit és realment només iguales de la VPN, l'abast el respon sense cap lògica d'estat de connexió: lligueu la regla a la interfície del túnel o al rang d'adreces del túnel, limiteu les adreces remotes al pool de clients i especifiqueu el tipus echo en lloc d'«ICMP». Aquesta regla continua sent correcta quan no hi ha cap VPN activa i no la pot obrir un perfil aliè.

Si el requisit és realment una porta pública, digueu-ho al text de la política, perquè els criteris d'acceptació canvien. Una porta pública ha de nomenar el perfil exacte, definir què vol dir «connectat» i declarar que els remitents públics són dins l'abast per disseny. La major part de la confusió desapareix en el moment que algú es veu obligat a escriure aquesta frase.

Construïu l'objecte un cop i després commutau-lo

Proveïu prèviament una sola regla amb una identitat estable, deshabilitada, i deixeu que el controlador només en canviï l'estat d'habilitació. Crear regles pel nom de visualització a cada execució és com un magatzem de polítiques acaba amb cinc objectes gairebé idèntics i sense cap manera fiable de treure'ls.

New-NetFirewallRule -Name "VpnGateEchoV4" -DisplayName "Public echo gated on VPN state" -Direction Inbound -Action Allow -Protocol ICMPv4 -IcmpType 8 -LocalAddress 203.0.113.10 -RemoteAddress Any -Enabled False
Set-NetFirewallRule -Name "VpnGateEchoV4" -Enabled True

El nom és l'identificador durador; el nom de visualització és documentació que una persona pot editar. Reconcilieu per -Name i l'script deixa de produir duplicats. La mateixa forma d'ordre cobreix el cas IPv6 amb -Protocol ICMPv6 -IcmpType 128, que és una regla separada perquè els números de tipus echo difereixen entre les dues famílies.

Manteniu la família d'adreces i el tipus d'ICMP explícits per una segona raó: -Protocol ICMPv4 sense un tipus permet tots els missatges ICMPv4 que el perfil admet, inclosos els que no volíeu acceptar mai. Nomenar el tipus 8 estreny la regla a la sol·licitud echo, que és l'única cosa que envia una comprovació d'abastabilitat.

On l'automatització contradiu la intenció

Enquestar un perfil de client cada pocs minuts no pot produir una frontera immediata. Entre la caiguda de la connexió i l'enquesta següent, la regla encara respon a l'adreça pública; entre l'aixecament de la connexió i l'enquesta següent, no. Reconèixer aquest retard és honest, i afirmar que el disseny imposa un invariant estricte no ho és.

Hi ha un parany d'abast a la mateixa comprovació d'estat. Get-VpnConnection informa dels perfils de client configurats a la màquina, per defecte per a l'usuari actual i per a tots els usuaris amb -AllUserConnection. No informa dels usuaris remots que en aquest moment marquen cap a un servidor RRAS; aquesta és una altra observació amb una altra ordre. Una porta construïda sobre la incorrecta no és connectada a res.

Després cobriu els estats que ningú no programa: arrencada amb la regla ja habilitada d'una execució anterior, caiguda del controlador amb la porta oberta i perfil esborrat mentre la seva regla continua activa. Cadascun necessita un valor per defecte definit, i el valor segur per a un permís públic és deshabilitat. Si el requisit no pot tolerar la finestra d'enquesta, una regla lligada a l'estat és l'instrument equivocat i l'aplicació pertany al túnel, no a la interfície pública.

Finalment, proveu la sol·licitud pública dues vegades, una amb la connexió seleccionada activa i una amb ella caiguda, des d'un amfitrió que no sigui a la VPN. Un ping correcte des de dins del túnel no demostra res sobre aquesta política, i aquesta és la mesura que la majoria de desplegaments s'estalvien.