Els dispositius locals desapareixen amb la VPN: tres fallades separades
El dispositiu pot respondre a la seva adreça després de desaparèixer de la llista. El descobriment, la resolució de noms i l’abast fallen per separat, així que proveu-los un per un.
Una impressora que desapareix de la llista de dispositius quan la VPN s’activa pot respondre encara a la seva adreça. La llista s’omple amb el descobriment, el nom pot venir d’un resolutor i el servei mateix s’assoleix per un sòcol, i els tres poden fallar de manera independent. Comparar què funciona a cada capa us diu quina funció canviar. Activar primer totes les excepcions d’accés local elimina les proves.
Aquesta és la diferència entre un dispositiu que falta i un dispositiu que simplement no s’anuncia.
Descobriment, noms i abast són tres capes
Els protocols de descobriment es basen en multicast o broadcast, i aquests no travessen un túnel encaminat per defecte, per això un dispositiu pot desaparèixer d’una llista mentre continua sent perfectament abastable. La resolució de noms és la segona capa: una VPN pot canviar el resolutor, i un nom que abans responia la xarxa local pot ara respondre’s en un altre lloc o no respondre’s. L’abast és la tercera: una ruta, una regla de tallafocs i un servei que escolta. Cada capa pot trencar-se mentre les altres dues estan bé.
Proveu-les de baix a dalt. Una sola comprovació d’abast fa evident la separació: nc -vz 192.168.1.20 443 o bé té èxit, cosa que vol dir que el camí i el servei estan bé i el sospitós és el nom, o bé falla, cosa que trasllada la pregunta a l’encaminament i la política. Després pregunteu pel nom. La primera fallada que trobeu és la capa on cal treballar, i les capes de sobre no la poden compensar.
Pregunteu primer per l’adreça i després pel nom d’amfitrió
Si l’adreça respon i el nom no, el problema és la resolució i no l’encaminament. Un client VPN que instal·la el seu propi resolutor pot canviar quin servidor respon els noms locals, i un que no reenvia el domini local deixa el nom sense resposta. Si l’adreça també falla, el problema és el camí: una ruta per defecte pel túnel, un bloqueig del trànsit local al costat del client o una regla de tallafocs que només permet la interfície física.
Si tots dos funcionen però el descobriment automàtic no, el dispositiu simplement no s’anuncia pel túnel. És el comportament esperat per al descobriment basat en multicast, no una fallada de configuració. Afegir el dispositiu per adreça sol ser la solució honesta.
Què canvia realment l’interruptor d’accés local
Un paràmetre d’accés a la xarxa local normalment permet que el trànsit a la subxarxa connectada directament eviti el túnel, i fa coses diferents en clients diferents. No configura el reenviament a una oficina remota i no canvia el tallafocs de l’amfitrió ni els permisos propis de l’aplicació. Tampoc no fa inequívoca una subxarxa superposada. Llegiu la documentació del client sobre què cobreix el paràmetre abans d’activar-lo de manera àmplia.
Una excepció estreta per a un sol dispositiu de confiança és millor que una autorització general, sobretot en una xarxa de convidats on el bloqueig pot ser deliberat. Una adreça privada no és una comprovació d’identitat, així que l’elecció depèn de la xarxa on sigueu.
Quan les xarxes se superposen
Si la xarxa de casa i la remota fan servir el mateix rang, l’encaminament es torna ambigu i ni l’interruptor d’accés local ni cap excepció ho resolen. Dos serveis a la mateixa adreça no es poden assolir tots dos, i quin guanya depèn de l’especificitat de la ruta i de l’ordre, no de la intenció. La solució és planificar les adreces, no un paràmetre del client. Comproveu els rangs abans de passar una nit amb la impressora.
Per a un dispositiu darrere la passarel·la remota, l’operador té el reenviament, la política d’amfitrió i la ruta de tornada. Una casella local al client no pot proporcionar-ne cap, i demanar-ho és més productiu que experimentar amb interruptors.
Anoteu quina capa ha fallat i què heu canviat. El proper dispositiu fallarà en un dels mateixos tres llocs.