Kill switch en Windows sen software extra: perfís ou rutas?

Os perfís da devasa seguen a categoría da rede, as rutas seguen o adaptador. Compare ambos e despois probe o caso da caída co túnel ausente e a icona mentindo.

O cliente morre a metade dunha descarga e a icona da bandexa desaparece. A transferencia segue pola conexión da casa. Esa secuencia é a razón pola que existe un kill switch, e Windows pode aproximarse a un sen un segundo produto.

Dous métodos merecen coñecerse. Fallan en sitios distintos, e ningún é unha resposta completa.

Método un: permitir o programa nun só perfil

A devasa de Windows limita as regras aos perfís Domain, Private e Public. O truco consiste en dar unha categoría ao adaptador do túnel e outra ao adaptador físico. Despois escribes unha regra de saída que permite o programa protexido no perfil do túnel e bloquéao en todos os demais sitios. A devasa le a categoría, non o nome do adaptador.

Primeiro pon a conexión VPN en Private e a rede física en Public. Logo engade unha regra de bloqueo para o programa que se aplique aos perfís que non queres. Despois confirma a asignación con Get-NetConnectionProfile, porque é esa asignación a que segue a regra.

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory

New-NetFirewallRule -DisplayName 'Block browser off VPN' -Direction Outbound `
  -Program 'C:\Program Files\Mozilla Firefox\firefox.exe' -Action Block -Profile Public

New-NetFirewallRule -DisplayName 'Allow browser on VPN' -Direction Outbound `
  -Program 'C:\Program Files\Mozilla Firefox\firefox.exe' -Action Allow -Profile Private

A debilidade é estrutural. Unha regra de perfil segue a categoría, así que cando Windows reclasifica unha rede de hotel o bloqueo pode deixar de aplicarse. Nada da lista de regras cambia cando iso ocorre.

Método dous: eliminar a ruta predeterminada física

O enfoque por rutas é máis contundente e moito máis doado de auditar. Anota a pasarela física, deixa que a VPN instale a súa propia ruta predeterminada cunha métrica máis baixa e despois borra a predeterminada física. Nada máis poderá transportar tráfico.

route print -4
route delete 0.0.0.0 mask 0.0.0.0 192.168.50.1
route print -4 | findstr /c:"0.0.0.0"

Cando o cliente morre, a ruta da VPN vaise co seu adaptador. A máquina queda sen conexión en lugar de filtrar, e iso é o que debe producir un kill switch.

Dous detalles deciden se aguanta unha semana. O DHCP devolve a pasarela cada vez que a ligazón parpadea. Un adaptador físico con enderezo estático evita esa sorpresa. O enderezo do propio servidor VPN tamén debe seguir sendo alcanzable. Sen esa ruta cara ao host o cliente non poderá reconectarse nunca tras a caída que activou o bloqueo.

Método tres: sen pasarela, unha ruta persistente ao host

A terceira opción comeza borrando a pasarela dos axustes do adaptador. Despois substitúea unha única ruta persistente ata o punto final da VPN. A máquina pode entón falar co servidor e con nada máis ata que o túnel se levante.

route -p add 198.51.100.44 mask 255.255.255.255 192.168.50.1 metric 1
route print -4 | findstr 198.51.100.44

Restaurar a pasarela restaura a internet normal, o que o converte nun interruptor limpo de acendido e apagado. Non depende dun script que vixía os eventos da interface. Tampouco lle importa como se categoriza a rede.

O custo é un illamento total mentres o túnel está caído. As actualizacións paran, e tamén a propia descarga que motivou o exercicio. Nun portátil de traballo adoita ser correcto, mentres que nunha máquina persoal é unha decisión que cómpre tomar a propósito.

Por que a icona do globo non demostra nada

Windows informa da accesibilidade mediante unha sonda contra un punto final de Microsoft. Esa sonda non di nada sobre o teu túnel. Un túnel conectado pode estar detrás dun globo que informa de que non hai internet, e un morto pode amosar unha conexión sa.

Proba matando o proceso do cliente e despois intenta alcanzar un enderezo público por número. Unha consulta de nome pode responderse desde a caché, así que nin a icona nin unha resposta DNS son probas.

Que rexistrar tras unha caída real

Executa a proba como unha secuencia e non como unha soa comprobación. Mata o proceso en lugar de desconectar e despois proba un enderezo numérico nas dúas familias. Restaura o cliente despois e confirma que segue alcanzando o seu propio servidor pola ruta que conservaches.

taskkill /IM openvpn-gui.exe /F
ping -4 198.51.100.44
ping -6 2606:4700:4700::1111
route print -4 | findstr /c:"0.0.0.0"

Repite a secuencia tras a suspensión, tras un cambio de Wi-Fi e tras pasar de cable a sen fíos. Eses tránsitos son onde fallan á vez o método do perfil e o comportamento do DHCP. Unha regra que aguanta nun escritorio non aguanta necesariamente nun hotel.

Escribe o paso de desfacer xunto a cada regra e ruta. Microsoft documenta a creación de regras de saída na súa referencia de regras da devasa de Windows, e é unha fonte mellor ca un titorial só con capturas de pantalla.

Artigos relacionados