¿Orden de los solucionadores de DNS o adición de rutas "exclusivas" en Mac OS X?

¿Orden de los solucionadores de DNS o adición de rutas "exclusivas" en Mac OS X?

Estoy trabajando en una empresa donde, por varias razones extrañas, tengo la siguiente configuración:

  • Ethernet: está en una red de invitados y tiene acceso a Internet
  • Wifi: está en una red corporativa y tiene acceso a la intranet
  • El orden del adaptador está configurado, de modo que Ethernet sea el primero.
  • route addse utiliza para agregar las rutas de intranet que necesito (10.[4/6/1/39].xx, etc.)

El problema ahora es que ciertos programas no funcionan, ya que no utilizan IP sino direcciones con nombre. En consecuencia scutil --dns, tiene el solucionador n.° 1 con servidores DNS externos y luego sigue el solucionador n.° 2 con los servidores DNS de la intranet. (si desconecto el cable y estoy solo en Wifi corp, los nombres se resuelven bien).

Pensé en dos posibles soluciones, pero no sé cómo hacerlas funcionar:

  • Aunque Wifi es el primer adaptador en orden, de alguna manera cambio el orden de resolución de DNS para que se pruebe el DNS de la intranet antes que el DNS de Internet.
  • coloque el adaptador Wifi en primer lugar y luego busque un comando de ruta "excluyente", que no dice "enviar IP X sobre en0" sino "enviar cualquier IP que no sea igual a X sobre en1"

¿Alguien puede ayudarme aquí?

Respuesta1

Parece que he estado trabajando en la misma empresa ;-)

Encuentre en el siguiente enlace un script Ruby que puede adaptar para hacer lo queHennes describe como opción 4), aunque utiliza el reenvío de solicitudes DNS en lugar de vistas. Sin embargo, esto debería ser fácil de solucionar. https://github.com/simonair/pubcode/blob/master/multihome_setup/multihome_setup.rb

Este script utilizará sudo según sea necesario.

Úselo sólo si comprende exactamente lo que hace.

Es mejor crear un nuevo Locationuso System Preferences > Networkantes de comenzar a experimentar con este script porque esto le permitirá deshacer cualquier cambio volviendo al bien conocido Location.

Qué hará:

  • Enumere todas las interfaces de red e identifique la que está conectada a la red corporativa y la que está conectada a la otra red según susPASARELAS PREDETERMINADASDirección IP (no la dirección asignada a la interfaz en sí)
  • Configure el servidor DNS integrado BINDpara manejar solicitudes tanto para la red corporativa como para Internet y reenviarlas por dominio. Por ejemplo, example.comse reenviará a los servidores de nombres corporativos, mientras que example.netse reenviará a los otros servidores de nombres.
  • Establecer enrutamiento a una lista de subredes a través de la interfaz corporativa, el resto a través de la otra red
  • Opcionalmente, también iniciará una conexión VPN si se configura correctamente.

Debe adaptar el guión a sus necesidades.

Tenga en cuenta que necesitallame nuevamente al script con el argumento restoreuna vez que se desconecte de la red corporativa,de lo contrario, todas las solicitudes de DNS llegarán a su servidor de nombres local y no podrá resolverlas fuera de su entorno corporativo.

Respuesta2

No estoy seguro de que esta sea una respuesta completa adecuada, pero ponerla en varios comentarios parece una tontería.

1) Solución rápida:

Agregue los nombres de la intranet al archivo de host. (Está dentro/privado/etc/hosts). Esto funciona si sólo necesitas acceso a unos pocos servidores y es relativamente fácil de hacer. También parece una tontería y si las IP del servidor alguna vez cambian, deberá actualizar manualmente su archivo de hosts.

2) Suponiendo que el servidor DNS en la intranet también gira nombres en Internet, solo puede usar ese servidor DNS. Considero que esto es poco probable ya que mencionaste explícitamente que la red de invitados tiene acceso a Internet y la otra a la intranet. (Podría ser si la intranet tiene acceso a Internet pero está bloqueado mediante algunas reglas de firewall que no bloquean todo. Por ejemplo, no el puerto 53).

3) Es posible que el uso de ambos servidores DNS (que es lo que está intentando hacer) no funcione.

No tengo una máquina OS/X para probar esto, pero recientemente aprendí por las malas que algunos sistemas operativos no consultan los servidores DNS en orden, ni recurren a un servidor de nombres secundario cuando falla el primero. En lugar de eso, parecen utilizar los servidores de nombres enumerados al azar.

El resultado de eso sería:
(ordenar DNS de Internet, DNS de intranet)
Consultar host en Internet -> funciona.
Consultar host en la intranet -> Error en la búsqueda a través del servidor DNS en Internet, abandone en lugar de intentarlo a continuación.

No sé si este es el caso en OS/X y no tengo un Mac para probarlo.

4)Servidor de nombres local

(En negrita porque creo que esta es la mejor solución).

OS/X viene conUNIRy parece fácilpermitirle. La palabra clave que desea buscar en BIND es vistas.

Respuesta3

Tuve un problema similar enMac OScon una serie de interfaces de red físicas y virtuales y la necesidad de solicitar resolución de nombres a diferentes servidores según la disponibilidad o no disponibilidad de esas interfaces de red.

Después de buscar en Google y probar, encontré la información más completa dentro de una discusión más amplia enhttps://rakhesh.com/infrastructure/macos-vpn-doesnt-use-the-vpn-dns. En resumen, para definir resolutores específicos yalterar las prioridades de resolución del sistema de macos, para cada necesidad de resolución específica mía (por ejemplo,"Se debe consultar el servidor DNS privado 10.10.10.128 para midominio.tld cuando sea accesible; de ​​lo contrario, el servidor DNS público 8.8.8.8 de Google") fue suficiente para

  1. cree un archivo en /etc/resolver (digamos /etc/resolver/per-domain-resolver o el nombre que más le guste)

  2. llénelo con una secuencia dedominio,nombre del servidor, yorden_búsquedadirectivas, por ejemplo

    domain mydomain.tld
    nameserver 10.10.10.128
    search_order 1
    nameserver 8.8.8.8
    

Podría valer la pena resaltar que mis pruebas se convirtieron en soluciones funcionales tan pronto como incorporaron eldominioyorden_búsquedadirectivas.

información relacionada