Tengo una configuración de laboratorio doméstico con algunas Raspberries Pi que usanavahipara anuncios de servicio: puedo enviarles ssh ssh pi@<hostname>.localen lugar de tener que recordar direcciones IP individuales. En particular, tenga en cuenta que esto no solo funciona desde mi computadora portátil, sino también desde los propios Pis; es decir, si hago ssh pi1, puedo hacerlo exitosamente .ssh [email protected]
Recientemente configuré unVPN de protección de cablesejecutándose en uno de los Pis para permitirme acceder a mi laboratorio doméstico incluso cuando estoy fuera de casa. Cuando uso esta VPN en mi computadora portátil, puedo hacer ssh a un pi con ssh pi@<LAN-IP-address-of-pi>, peronocon ssh pi@<hostname>.local.
¿Porqué es eso? Mi comprensión (ciertamente básica) de las VPN es que funcionan haciendo que su conexión se comporte "como si" se originara en el servidor VPN. Si ese es el caso, ¿por qué obtendría un comportamiento ssh diferente a través de una VPN que desde el propio servidor VPN? O, si ese no es el caso, ¿cómo es que es incorrecto?
Mi intuición es que la resolución DNS no se realiza a través de la VPN: cuando comparo los resultados de dig pi.localmi computadora portátil VPN y los del servidor VPN, obtengo resultados diferentes (no comparto toda la carga útil ya que no sé lo suficiente sobre redes y seguridad para saber qué es seguro compartir y qué no):
- desde mi computadora portátil, la
;SERVERlínea hace referencia8.8.8.8(que creo que es un servidor DNS estándar propiedad de Google, que correctamente "no conocería" la dirección IP de mi Pi en la LAN) - Desde el servidor VPN, la
;SERVERlínea hace referencia a la dirección IP de LAN de mi LAN.agujero pi
Curiosamente, sin embargo, ninguna de las respuestas contiene realmente una ANSWERsección o la dirección IP real del Pi.
Respuesta1
Mi intuición es que la resolución DNS no pasa por la VPN.
Ya sea que lo haga o no, eso no afecta a mDNS (Avahi). Los .localnombres se resuelven mediante un solucionador mDNS independiente, sin utilizar el solucionador DNS de unidifusión estándar, y el objetivo de mDNS es que funciona sin servidores DNS; Funciona transmitiendo un paquete de consulta a toda la subred local.
(Multidifusión, técnicamente, pero como tiene un alcance de enlace, puedes fingir que es lo mismo que una transmisión local).
En realidad no deberías conseguircualquierRespuestas "RESPONDER" de dig whatever.local, incluso si se hace referencia a Pi-Hole. En caso de que obtenga una respuesta de Pi-Hole, eso no es Avahi/mDNS, es solo DNS normal. (Los enrutadores domésticos implementan DNS local recopilando nombres de host de solicitudes de arrendamiento de DHCP; pero generalmente no recopilan anuncios de mDNS, incluso si usted tiene .localel dominio DNS, lo cual no debería).
¿Porqué es eso? Mi comprensión (ciertamente básica) de las VPN es que funcionan haciendo que su conexión se comporte "como si" se originara en el servidor VPN. Si ese es el caso, ¿por qué obtendría un comportamiento ssh diferente a través de una VPN que desde el propio servidor VPN? O, si ese no es el caso, ¿cómo es que es incorrecto?
En términos más generales, las VPN funcionan medianteconectándotea una red junto con el servidor VPN. Se podría decir que forman una LAN virtual a través de Internet. Ellosnonecesariamente enmascare sus conexiones o haga que parezca que se está conectando "como si" el servidor VPN – eso se hace por separado si es necesario. (El enmascaramiento no es una característica específica de VPN, es exactamente la misma NAT que se usaría con las LAN físicas).
(Esa es la verdadera diferencia entre VPN y proxies, aparte de la distinción de capa OSI. El propósito principal de un servidor proxy es transmitir solicitudes para que provengan "como si" del proxy. El propósito principal de una VPN es construir una red virtual).
La mayoría de los tipos de VPN no te conectan directamente al servidor VPN.existentered, sin embargo, sino crear unanuevouno. Tiene dos redes separadas: la "LAN" creada por VPN y la LAN física, con el servidor VPN actuandocomo enrutadorentre. Como lo haría un enrutador físico eth0 eth1 eth2o LAN/WAN, su servidor VPN se enruta entre eth0(la LAN) y wg0(la VPN WireGuard).
Al igual que con dos subredes físicas separadas por un enrutador, las dos pueden intercambiar paquetes regulares (unidifusión) entre dispositivos, pero un enrutador no los transmitirá.transmisiones localesentre subredes, ni retransmitirá las multidifusiones de alcance de enlace que utiliza mDNS. Entonces, cuando su cliente VPN envía una consulta de multidifusión mDNS, solo llega hasta la subred "local" entre el cliente VPN y el servidor VPN. Nunca se reenvía desde la interfaz wg0 del servidor a través de eth0 o cualquier otra cosa. Para que esto funcione, el servidor VPN probablemente necesitaría ejecutar su propio demonio avahi en modo "retransmisión" o "reflector", donde envía las consultas mDNS recibidas a otras interfaces y envía respuestas.
Además, muchas conexiones VPN en realidad no emulan una interfaz "capaz de transmisión" como Ethernet, lo que hace imposible el uso de paquetes de transmisión y multidifusión. WireGuard en particular forma una especie de red "punto a multipunto" donde se parece más a un conjunto de conexiones uno a uno debajo del capó: todas ellas están ocultas detrás de una única interfaz wg0, pero internamente utiliza AllowedIP para decidir. a qué par enviar cada paquete, y no hace excepción para transmisiones o multidifusiones. Más o menos lo mismo se aplica a OpenVPN en su modo "tun" predeterminado (o casi cualquier otra cosa que use interfaces "tun").
Pero algunas otras VPN, como OpenVPN en modo "tap", así como software como Tinc o ZeroTier,haceremular una red tipo Ethernet con direccionamiento de capa 2, lo que les permite manejar multidifusiones y difusiones de una forma más convencional. De hecho, en su mayoría simplemente emulan Ethernet normal, lo que permite que el servidor VPNpuentelas interfaces VPN y LAN en lugar de enrutar entre ellas. Si configura una VPN "puente", los clientes VPN conectados pasarán a formar parte de la misma subred LAN que los dispositivos locales y automáticamente podrán ver las transmisiones mDNS de los demás.
(La desventaja es, también, que verán las transmisiones mDNS de cada uno, y las transmisiones ARP, y las transmisiones de Dropbox, y las transmisiones UPnP/SSDP, y las transmisiones NetBIOS, y las transmisiones WS-Discovery, y una gran cantidad de ruido de fondo).