Obligar al sistema a usar el archivo de hosts locales antes de DNS (OS X El Capitan)

Quiero encontrar una manera de obligar a mi sistema a resolver a través del archivo de hosts locales en mi sistema antes de realizar una consulta de DNS. Hay una razón para esto, y aquí está mi contexto:

  • Yo vivo en China. Necesito una VPN para acceder a la Internet 'real'. En mi caso estoy usando Astrill .
  • Dentro de mi empresa, su DNS local apunta nuestra intranet, wiki y otros recursos en línea a direcciones IP locales. Cuando está fuera de la empresa, las entradas de DNS son obviamente las que están disponibles en las IP externas para todos.

Cuando estoy conectado a la VPN, no quiero que mi máquina busque por IP pública, quiero seguir usando la IP local que me da el DNS local, pero todo el tráfico pasa por la VPN.

Una solución que se me ocurrió fue poner las direcciones IP locales en una entrada de DNS en el archivo de hosts.

Luego leí sobre una técnica * nix que usa un archivo llamado nsswitch.confpara decirle al sistema que siempre use el archivo primero, luego el DNS. Pero OS X no parece usar esto (el archivo no existe de /etc/todos modos).

Esto sería ideal porque entonces siempre podría intentar usar el recurso local dondequiera que esté: Internet normal, conexión VPN, o dentro o fuera de mi empresa.

No puedo encontrar ninguna documentación para el soporte de OS X nsswitch.confo información sobre si verifica automáticamente los hosts antes que el DNS de todos modos.

¡Creo que no entiendes cómo funciona la resolución de DNS y VPN! Además, hay una diferencia si usa VPN (¡y qué tipo de VPN ! ) . Por favor, reelabore su pregunta.
No estoy seguro de cómo puedo volver a trabajar en mi pregunta sin más orientación. Lo pregunté dados los detalles que conozco. Uso Astrill como servicio. Solo tiene una opción de 'tunnel de sitios internacionales', que tuneliza todo excepto una lista disponible aquí: github.com/shadowsocks/ChinaDNS/blob/master/chnroute.txt (que es el rango de direcciones IP de China). Todavía no puedo acceder a los recursos locales cuando estoy conectado, aunque algunas direcciones IP EXTERNAS no están canalizadas a través de la VPN.
Depende en parte de la aplicación VPN que esté utilizando. Algunos proveedores de VPN como el mío proporcionan una aplicación que me permite canalizar todo el tráfico o solo el tráfico saliente. Al mismo tiempo, también puedo usar Tunnelblick (como la aplicación "estándar") para usar el mismo servicio VPN con un comportamiento algo diferente. El problema de la mayoría de los proveedores de VPN (que venden sus servicios en la República Popular China) es la carrera continua entre la altura y el grosor crecientes del GF y los "perforadores de túneles". Y cada día es más complicado.
Hasta ahora ni siquiera sabíamos qué proveedor de servicios había elegido y todavía no sabemos si usa Tunnelblick o alguna aplicación personalizada (como la aplicación Astrill).
"Todavía no sabemos si usa Tunnelblick o alguna aplicación personalizada (como la aplicación Astrill)". - mmm, decir que? Dije que usé Astrill. "¡Creo que no entiendes cómo funciona la resolución de DNS y VPN!" - críticas inútiles. Entiendo cómo funciona el DNS. Esta es una pregunta de software sobre OSX y cómo funciona su resolución. Quiero decir, ¿qué tan útil crees que estás siendo al hacer estos comentarios? Ciertamente, no parece que simplemente esté tratando de 'mejorar la calidad de las preguntas'.
Lo siento, si mis comentarios suenan groseros. Esto no fue intencionado. Para mí, parece un llamado problema xy. OS X siempre usa primero las entradas del archivo de los hosts. ¡Excepto cuando una aplicación usa su propio mecanismo de resolución de dns! Siempre que no tenga mangueras ni esté deformado. Como resultado, necesito más detalles sobre las aplicaciones involucradas, la configuración de las aplicaciones y el entorno de red de su empresa. Y: todavía estoy buscando una respuesta que resuelva su problema. Probablemente sea una combinación de dnsmasq y chinadns-c (ambos se pueden instalar con brew) y configuraciones especiales para su cliente VPN.
Fresco. Había oído hablar de dnsmasq pero no de chinadns-c. Tendré que echar un vistazo. Vale la pena señalar que cuando uso la aplicación Astrill, tampoco puedo hacer ping a las direcciones IP directamente. Esta puede ser una pregunta no relacionada, pero afecta a esta, como que la aplicación elimina por completo el acceso a la red local mientras estoy conectado a la VPN.
@xengrapher La mayoría de las aplicaciones VPN personalizadas tienen un interruptor en algún lugar para deshabilitar/habilitar "todo el tráfico se enruta a través de la conexión VPN". Por ejemplo, Tunnelblick (como un cliente openvpn gratuito que también debería funcionar con astrill) también tiene la función. Mi problema aquí en Alemania es que realmente no puedo reproducir el comportamiento de GF (incluido el envenenamiento de DNS). Así que podría encontrar una solución que funcione aquí, aunque no funciona en absoluto en la República Popular China.
por desgracia, Astrill lo hace, pero en realidad no son lo mismo. Tiene 4 opciones: 1. Túnel todo 2. Túnel todo excepto + una lista que acepta nombres de host, IP o redes (p. ej., 10.0.0.0/24) 3. Túnel nada, excepto + + una lista que acepta nombres de host, IP o redes ( p. ej., 10.0.0.0/24) 4. Túnel solo sitios internacionales

Respuestas (1)

Este ya es el valor predeterminado en OS XIe si especifica un nombre de host en el archivo de hosts, las búsquedas utilizarán la dirección IP que especificó allí en lugar de realizar una búsqueda de DNS.

Tenga en cuenta que esto solo es cierto para los programas que utilizan las funciones de resolución estándar del sistema. Los programas pueden usar su propio mecanismo de resolución que no garantiza que respete nada de lo que escriba en el archivo de hosts. Sin embargo, esos programas deberían ser raros y distantes entre sí.

Parece ser diferente cuando tethering. Cuando estoy conectado a mi iPhone, parece que incluso para una URL de dirección IP, el sistema primero prueba el DNS antes de poder conectarse a 127.0.0.1, lo que lo hace terriblemente lento.