Os dispositivos locais desaparecen coa VPN: tres fallos separados

Unha impresora que desaparece da lista de dispositivos cando se levanta a VPN pode seguir respondendo no seu enderezo. A lista énchea o descubrimento, o nome pode vir dun resolvedor e ao servizo en si chégase por un socket, e os tres poden fallar de forma independente. Comparar que funciona en cada capa díxolle que función cambiar. Activar primeiro todas as excepcións de acceso local elimina as probas.

Esa é a diferenza entre un dispositivo que falta e un dispositivo que simplemente non se anuncia.

Descubrimento, nomes e accesibilidade son tres capas

Os protocolos de descubrimento dependen de multicast ou broadcast, e estes non atravesan un túnel encamiñado por defecto, por iso un dispositivo pode desaparecer dunha lista mentres segue sendo perfectamente accesible. A resolución de nomes é unha segunda capa: unha VPN pode cambiar o resolvedor, e un nome que antes respondía a rede local agora pode responderse noutro sitio ou non responderse. A accesibilidade é a terceira: unha ruta, unha regra de cortafogos e un servizo que escoita. Cada capa pode romper mentres as outras dúas están ben.

Próbeas de abaixo cara arriba. Unha soa comprobación de accesibilidade deixa clara a separación: nc -vz 192.168.1.20 443 ou ten éxito, o que significa que a ruta e o servizo están ben e o nome é o sospeitoso, ou falla, o que traslada a pregunta ao encamiñamento e á política. Logo pregunte polo nome. O primeiro fallo que atope é a capa na que hai que traballar, e as capas superiores non poden compensalo.

Pregunte primeiro polo enderezo e despois polo nome de host

Se o enderezo responde e o nome non, o problema é a resolución e non o encamiñamento. Un cliente VPN que instala o seu propio resolvedor pode cambiar que servidor responde os nomes locais, e un que non reenvía o dominio local deixa o nome sen resposta. Se o enderezo tamén falla, o problema é a ruta: unha ruta por defecto polo túnel, un bloqueo do tráfico local no lado do cliente ou unha regra de cortafogos que só permite a interface física.

Se ambas funcionan pero o descubrimento automático non, o dispositivo simplemente non se anuncia polo túnel. É o comportamento esperado para o descubrimento baseado en multicast, non un fallo de configuración. Engadir o dispositivo por enderezo adoita ser a solución honesta.

Que cambia realmente o interruptor de acceso local

Un axuste de acceso á rede local normalmente permite que o tráfico cara á subrede conectada directamente evite o túnel, e fai cousas distintas en clientes distintos. Non configura o reenvío a unha oficina remota e non cambia o cortafogos do host nin os permisos propios da aplicación. Tampouco fai inequívoca unha subrede superposta. Lea a documentación do cliente sobre que cobre o axuste antes de activalo de forma ampla.

Unha excepción estreita para un só dispositivo de confianza é mellor que unha autorización xeral, sobre todo nunha rede de convidados onde o bloqueo pode ser deliberado. Un enderezo privado non é unha comprobación de identidade, así que a elección depende da rede na que estea.

Cando as redes se solapan

Se a rede doméstica e a remota usan o mesmo rango, o encamiñamento vólvese ambiguo e nin o interruptor de acceso local nin unha excepción o resolven. Dous servizos no mesmo enderezo non se poden alcanzar ambos, e cal gaña depende da especificidade da ruta e da orde, non da intención. A solución é a planificación de enderezos, non un axuste do cliente. Comprobe os rangos antes de pasar unha noite coa impresora.

Para un dispositivo detrás da pasarela remota, o operador é dono do reenvío, da política do host e da ruta de volta. Unha caixa local no cliente non pode achegar ningunha delas, e pedilo é máis produtivo que experimentar con interruptores.

Anote que capa fallou e que cambiou. O seguinte dispositivo fallará nun dos mesmos tres sitios.