O kill switch bloquea a túa impresora? Tres comprobacións que facer primeiro

A túa impresora funcionaba hai unha hora. Despois activaches a VPN e agora os traballos quedan na cola ata que fallan. O kill switch é a causa probable, non a impresora: descarta o tráfico que sairía do equipo fóra do túnel, e unha impresora de LAN é exactamente ese tipo de tráfico. A decisión real non é como arranxar a impresión, senón se este dispositivo debería chegar á rede local. Tres condicións resólveno, e calquera delas pode rematar a discusión antes de tempo.

Que descarta o kill switch e por que

Un kill switch é unha regra de encamiñamento cun modo de fallo asociado. Co túnel activo, os paquetes coincidentes saen cifrados; cando o túnel cae, o cliente manda a ruta predeterminada a un burato negro para que nada saia en texto plano. Unha impresora na mesma subrede nunca coincide coa ruta do túnel, así que se trata como un intento de fuga aínda que o tráfico nunca saia do edificio.

O descubrimento fai que o síntoma sexa confuso. As impresoras anúncianse por DNS multicast no porto 5353, e a cola do diálogo de engadir impresora constrúese con eses anuncios. Mentres o bloqueo está activo pode que o anuncio non chegue, así que a impresora desaparece da lista aínda que o seu enderezo siga respondendo. IPP no 631, impresión bruta no 9100 e SMB no 445 son servizos de LAN correntes sen ningún camiño polo túnel.

Primeiro demostra que a impresora é accesible

Antes de cambiar calquera política, confirma que a impresora está ben e confirma o enderezo que cres que ten. Le o enderezo do panel da impresora ou da súa propia páxina web. Unha entrada obsoleta na lista do sistema operativo pode apuntar a un enderezo que DHCP deu a outro dispositivo hai semanas.

Desconecta a VPN e despois proba o enderezo e os dous portos de impresión habituais:

nc -vz 192.168.1.50 9100
nc -vz 192.168.1.50 631

En Windows o equivalente é Test-NetConnection 192.168.1.50 -Port 9100. Volve conectar a VPN e repite. Se os portos responden coa VPN desactivada e esgotan o tempo con ela activada, reproduciu o bloqueo e o resto é unha cuestión de política. Se fallan nos dous estados, detente: a culpa é da impresora, do segmento Wi-Fi ou do illamento de clientes, e unha excepción de VPN só engadiría exposición.

Tres condicións que deciden permitir ou bloquear

Execútaas en orde. A primeira condición que falla decide o resultado, así que as seguintes non fai falta probalas.

As redes de convidados son o non máis claro. Nun segmento de hotel, o rango local é todos os demais convidados, así que unha excepción que chega á túa impresora tamén chega aos seus portátiles. Unha impresora que non é túa non é motivo para abrir ese segmento.

Os dispositivos xestionados son o segundo non. Cando un perfil de administrador impón VPN sempre activa con bloqueo, o cliente volve impor o bloqueo tras calquera cambio local, e a alternativa pode incumprir a política que aceptaches. Pide unha vía admitida cara ao recurso local en lugar de editar axustes que se sobrescribirán.

A excepción máis pequena que admite o teu cliente

O que queres é unha regra limitada ao destino para un enderezo de impresora, non un interruptor xeral de permitir local. Un interruptor xeral adoita cubrir todo o rango privado e o tráfico link-local, que é moito máis do que necesita unha cola de impresión, e converte cada dispositivo do segmento nun par que aceptaches.

Windows expón split tunnelling, e algunhas compilacións tamén expoñen unha opción de rede local. Onde a única ruta admitida é unha entrada de host, engade un só enderezo a través da pasarela física despois de levantar o túnel, por exemplo route add 192.168.1.50 mask 255.255.255.255 192.168.1.1, e bórrao cando remate a sesión. WireGuard funciona distinto: AllowedIPs decide que entra no túnel, así que un perfil de túnel completo 0.0.0.0/0 leva o traballo de impresión ao extremo salvo que unha ruta máis específica o evite, e wg-quick pode instalar regras de cortalumes que bloqueen todo o demais.

En Android o axuste sempre activo que bloquea as conexións sen a VPN é o kill switch, e o descubrimento de impresoras desde unha aplicación dentro dese bloqueo non ten camiño de LAN. O modelo por aplicación e de exclusións está documentado na páxina de VPN de Android, que é onde hai que mirar antes de cambiar nada: Guía de conectividade VPN de Android. As versións recentes de macOS piden permiso de rede local por separado do túnel, e iOS fai o mesmo para o acceso á rede local, pero a cola aínda pode fallar co túnel activo porque o cliente do fabricante encamiña a subrede dentro del.

Sexa cal sexa o cliente que uses, mantén a excepción nun só enderezo e os dous ou tres portos que a impresora usa de verdade. Reserva unha concesión DHCP en lugar de ampliar a regra a toda a subrede, porque o enderezo pode cambiar.

Verifica a excepción e sabe cando desfacela

Despois do cambio, volve conectar e comproba tres cousas en orde. A impresora responde nos seus portos, imprímese unha páxina de proba inofensiva e unha consulta de enderezo segue devolvendo o extremo da VPN en lugar do teu ISP. Se a impresión funciona pero a consulta mostra o teu ISP, abriches máis que a impresora e deberías revertir.

Repite a proba tras un reinicio e tras calquera actualización do cliente ou do perfil, porque as actualizacións restauran os valores predeterminados con bastante frecuencia como para importar. Unha excepción que só sobrevive ata a próxima reconexión non é unha decisión, é un burato temporal. Escribe a regra exacta para poder quitarla a propósito.

Se o dispositivo está pensado só para o túnel, un portátil de viaxe ou unha máquina con datos de clientes, a resposta correcta é manter o bloqueo e imprimir noutro sitio: garda en PDF e imprime desde un teléfono ou outra máquina, ou chega a un servidor de impresión que o túnel poida encamiñar. Desactivar o kill switch para un traballo cambia unha protección real por unha pequena comodidade.