3 votos

Jeremy Impson avatar

Apple MacOS parece ignorar la ruta por defecto asignada desde DHCP

Preguntado el 30 de Octubre, 2019
Cuando se hizo la pregunta
82 visitas
Cuantas visitas ha tenido la pregunta
2 Respuestas
Cuantas respuestas ha tenido la pregunta
Resuelta
Estado actual de la pregunta

Mi equipo se ha encontrado con el siguiente problema. Hemos descubierto una solución operacionalmente aceptable que presentaré como respuesta a esta pregunta, pero esperamos una solución mejor, o al menos una mejor explicación de lo que está pasando.

Estamos intentando llevar algunos productos de Apple a nuestro laboratorio de pruebas para definir configuraciones para nuestro cliente. Los ejemplos y las pruebas se realizaron en un Macbook Air, pero se confirmó que el problema existe en algunos modelos antiguos de iPhone e iPads. Lo hemos puesto en una de las redes Ethernet inalámbricas del laboratorio, donde recibe la configuración DHCP de un Cisco 5921 ESR (router de software) como se esperaba, incluyendo la IP, la máscara de red y la ruta por defecto. El MacBook está en la red 192.168.1.0/24, y en los siguientes casos de prueba, la red remota es 192.168.2.0/24.

Los resultados completos de ifconfig y netstat -nr del MacBook están al final de esta pregunta.

El problema es que mientras puede comunicarse con otros dispositivos en su subred local, cualquier comunicación no local que debería ir a la pasarela está fallando. Todo tipo de tráfico de red a destinos no locales falla (ping, web, ssh). Y el wireshark que se ejecuta en el MacBook muestra que el tráfico ARP e IP esperado se produce cuando se comunica con los nodos locales, incluso con el propio router. Pero no se genera absolutamente ningún tráfico cuando se intenta conectar con tráfico no local, ni siquiera una petición ARP. Sin embargo, la tabla de enrutamiento parece especificar la interfaz correcta y la dirección de la puerta de enlace para la entrada por defecto.

Ejecución de route get produce lo siguiente, primero para local (que funciona) y para no local (que no funciona):

MacBook-Air:~ user1$ route get 192.168.1.1
   route to: 192.168.1.1
destination: 192.168.1.1
  interface: en0
      flags: <UP,HOST,DONE,LLINFO,WASCLONED,IFSCOPE,IFREF,ROUTER>
 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
       0         0         0         0         0         0      1500      1175 

MacBook-Air:~ user1$ route get 192.168.2.80
route: writing to routing socket: not in table

Y ping primero para los locales y luego para los no locales

MacBook-Air:~ user1$ ping  192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttl=255 time=2.904 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=255 time=3.963 ms
^C
--- 192.168.1.1 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.904/3.433/3.963/0.529 ms

MacBook-Air:~ user1$ ping  192.168.2.80
PING 192.168.2.80 (192.168.2.80): 56 data bytes
ping: sendto: No route to host
ping: sendto: No route to host
Request timeout for icmp_seq 0
ping: sendto: No route to host
Request timeout for icmp_seq 1
ping: sendto: No route to host
Request timeout for icmp_seq 2
^C
--- 192.168.2.80 ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss

Después de comprobar lo básico (máscara de red, rutas por defecto, cortafuegos), investigamos un poco más que nos llevó a esto pregunta

En él, el problema era que la ruta por defecto está etiquetada con la letra I. En mi sistema, este es también el caso, como se ve en esta salida parcial de netstat -nr:

Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            192.168.1.1        UGScI           4        0     en0

Según la pregunta anterior, la letra I significa

I       RTF_IFSCOPE      Route is associated with an interface scope

Puedo confirmar esto ejecutando ping con la bandera -b, y ejecutando route get con la bandera -ifscope (notar esto es lo que nos llevó a buscar RTF_IFSCOPE que llevó al post de stackexchange anterior). Cuando se utilizan estas banderas, ambos comandos funcionan como se espera. Sin sus respectivas banderas, ambos comandos fallan.

MacBook-Air:~ user1$ route get -ifscope en0 192.168.2.80
   route to: 192.168.2.80
destination: 192.168.2.80
    gateway: 192.168.1.1
  interface: en0
      flags: <UP,GATEWAY,HOST,DONE,WASCLONED,IFSCOPE,IFREF>
 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
       0         0         0         0         0         0      1500         0 

MacBook-Air:~ user1$ ping -b en0  192.168.2.80
PING 192.168.2.80 (192.168.2.80): 56 data bytes
64 bytes from 192.168.2.80: icmp_seq=0 ttl=61 time=3.206 ms
64 bytes from 192.168.2.80: icmp_seq=1 ttl=61 time=2.713 ms
64 bytes from 192.168.2.80: icmp_seq=2 ttl=61 time=3.246 ms
64 bytes from 192.168.2.80: icmp_seq=3 ttl=61 time=3.001 ms
64 bytes from 192.168.2.80: icmp_seq=4 ttl=61 time=2.444 ms
64 bytes from 192.168.2.80: icmp_seq=5 ttl=61 time=2.426 ms
64 bytes from 192.168.2.80: icmp_seq=6 ttl=61 time=2.205 ms
64 bytes from 192.168.2.80: icmp_seq=7 ttl=61 time=4.701 ms
64 bytes from 192.168.2.80: icmp_seq=8 ttl=61 time=4.964 ms
64 bytes from 192.168.2.80: icmp_seq=9 ttl=61 time=2.674 ms
^C
--- 192.168.2.80 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.205/3.158/4.964/0.898 ms

Así, RTF_IFSCOPE parece la versión BSD de Linux Network Namespaces o Cisco IOS VRFs (me doy cuenta de que puede ser anterior a estos). Pero en mi caso, la ruta por defecto está configurada por DHCP, así que no está claro cómo o por qué esto llegó a ser, ni cómo cambiarlo al ámbito por defecto (o, alternativamente, hacer que todas las aplicaciones utilicen el ámbito especial).

Como prueba, he añadido manualmente una segunda ruta por defecto:

sudo route -r add default 192.168.1.1

La ruta resultante no tiene una bandera I asociada:

Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            192.168.1.1        UGSc           4        0     en0
default            192.168.1.1        UGScI           4        0     en0

Esto soluciona el problema, permitiendo ahora que toda la comunicación de red no local funcione. No consideramos que sea una solución operativa aceptable, especialmente para iPhone y iPad, ya que, por lo que sabemos, sería necesario añadir aplicaciones a los dispositivos para poder añadir rutas manuales.

Sospechamos que algo en nuestro entorno de red está causando este comportamiento. Pero no estamos seguros de qué es.

Los siguientes resultados de ifconfig y netstat -nr son del Macbook Air:

MacBook-Air:~ user1$ ifconfig 
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
    options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>
    inet 127.0.0.1 netmask 0xff000000 
    inet6 ::1 prefixlen 128 
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
    nd6 options=201<PERFORMNUD,DAD>
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
OHC4: flags=0<> mtu 0
EHC36: flags=0<> mtu 0
OHC6: flags=0<> mtu 0
EHC38: flags=0<> mtu 0
en0: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
    ether 04:0c:ce:cf:be:ac 
    inet 192.168.1.52 netmask 0xffffff00 broadcast 192.168.1.255
    nd6 options=201<PERFORMNUD,DAD>
    media: autoselect
    status: active
p2p0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 2304
    ether 06:0c:ce:cf:be:ac 
    media: autoselect
    status: inactive
utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 2000
    inet6 fe80::d380:8cb1:83eb:3753%utun0 prefixlen 64 scopeid 0xa 
    nd6 options=201<PERFORMNUD,DAD>

MacBook-Air:~ user1$ netstat -nr 
Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            192.168.1.1        UGScI           4        0     en0
127                127.0.0.1          UCS             0        0     lo0
127.0.0.1          127.0.0.1          UH              1      130     lo0
169.254            link#8             UCS             0        0     en0
192.168.1          link#8             UCS             3        0     en0
192.168.1.1/32     link#8             UCS             1        0     en0
192.168.1.1        0:1b:ac:1:79:9a    UHLWIir         3       60     en0
192.168.1.52/32    link#8             UCS             0        0     en0
192.168.1.53       2c:be:8:aa:47:98   UHLWI           0        2     en0    472
192.168.1.54       88:1f:a1:7a:6d:5a  UHLWI           0        0     en0   1200
192.168.1.56       2c:be:8:9d:ff:78   UHLWI           0       10     en0    817
224.0.0/4          link#8             UmCS            1        0     en0
224.0.0.251        1:0:5e:0:0:fb      UHmLWI          0        0     en0
255.255.255.255/32 link#8             UCS             0        0     en0

Internet6:
Destination                             Gateway                         Flags         Netif Expire
default                                 fe80::%utun0                    UGcI          utun0
::1                                     ::1                             UHL             lo0
fe80::%lo0/64                           fe80::1%lo0                     UcI             lo0
fe80::1%lo0                             link#1                          UHLI            lo0
fe80::%utun0/64                         fe80::d380:8cb1:83eb:3753%utun0 UcI           utun0
fe80::d380:8cb1:83eb:3753%utun0         link#10                         UHLI            lo0
ff01::%lo0/32                           ::1                             UmCI            lo0
ff01::%utun0/32                         fe80::d380:8cb1:83eb:3753%utun0 UmCI          utun0
ff02::%lo0/32                           ::1                             UmCI            lo0
ff02::%utun0/32                         fe80::d380:8cb1:83eb:3753%utun0 UmCI          utun0
Preguntado el 30 de Octubre, 2019 por Jeremy Impson

Respuestas

¿Demasiados anuncios?

7voto

Jose Chavez avatar
Jose Chavez Puntos 645

Creo que la pieza que falta en tu rompecabezas es que Apple utiliza una forma ligeramente diferente de manejar la prioridad de la interfaz que otros sistemas operativos populares.

Por ejemplo, si tomamos un escenario de usuario doméstico normal, los productos de Apple intentarán priorizar el tráfico sobre la mejor conexión a Internet disponible. Si tienes una conexión a Internet tanto por Ethernet como por WiFi, utilizará la conexión por cable antes que la inalámbrica.

La forma en que esta priorización se realiza técnicamente es a través de la bandera RTF_IFSCOPE, que ha experimentado. Esencialmente, el sistema marcará la ruta de menor prioridad con la bandera RTF_IFSCOPE para asegurarse de que sólo se utiliza si se solicita específicamente (es decir, por ejemplo, si tiene un programa VPN que utiliza una conexión específica, podrá hacerlo).

Puedes observar lo mismo si te conectas a una WiFi sin conexión a Internet o a una WiFi con un portal cautivo en el que no hayas iniciado sesión. En un dispositivo iOS, por ejemplo, verás que el símbolo de la WiFi en la parte superior cambia a una onda superpuesta con un signo de exclamación (!). Podrás seguir utilizando la interfaz y comunicarte con los dispositivos de esa subred específica, pero no se utilizará como puerta de enlace predeterminada, a menos que se solicite específicamente.

Así que en tu caso parece que ya tienes una puerta de enlace por defecto en el Mac antes de conectarlo al WiFi. Como el servidor DHCP del WiFi no da una opción 6 (es decir, la lista de servidores DNS), el sistema dará a esta conexión una prioridad menor.

Parece que debería poder resolver el problema al no tener una ruta por defecto antes de conectarse al WiFi.

Una solución más común sería simplemente especificar la priorización que desea en lugar de confiar en los valores predeterminados automáticos. Esto se hace en el Mac en Preferencias del Sistema > Red. Haz clic en el icono del engranaje debajo de la lista de la izquierda y elige "Establecer orden de servicio". Ahora arrastre la interfaz Wi-Fi por encima de la otra interfaz de ruta por defecto que tenga (por ejemplo, Ethernet). Esto elimina la bandera REF_IFSCOPE de su WiFi. También puede hacer esto a través de la línea de comandos, o desde un servidor de gestión central, por supuesto - pero la ruta GUI es la forma más fácil de probar esto rápidamente.

Aparte de eso, diría que tu configuración suena relativamente poco común. No estoy de acuerdo con su elección en renunciar específicamente a los servidores DNS simplemente para evitar la reconfiguración de los servidores web de hacer búsquedas inversas en las direcciones IP. Las búsquedas inversas se seguirán haciendo, pero se manejarán localmente.

Parece que sería una mejor opción tener servidores DNS y configurar razonablemente los servidores web en su lugar. Se puede configurar un servidor DNS para que responda estáticamente a todas las búsquedas inversas en lugar de buscar algo en Internet o gastar tiempo en proporcionar nombres.

Respondido el 30 de Octubre, 2019 por Jose Chavez (645 Puntos )

3voto

Jeremy Impson avatar
Jeremy Impson Puntos 13

Descubrimos esta referencia al buscar más información sobre las causas de que los productos de Apple se comporten así.

Por razones que no me quedan claras, cuando un dispositivo Apple que utiliza Ethernet inalámbrica no recibe una configuración de servidor DNS a través de DHCP, coloca la información de enrutamiento que recibe en un ámbito de red diferente del ámbito por defecto, impidiendo así cualquier comunicación no local. Cuando la oferta de DHCP contiene una opción de Servidor DNS, este problema no se produce, y cuando la red es Ethernet cableada, el problema no se produce independientemente de que haya una configuración de Servidor DNS en la oferta de DHCP.

Nuestro entorno de red es independiente y no se utiliza la resolución de nombres DNS. Así que nuestros servidores DHCP no proporcionan la opción 6 de DHCP, también conocida como "dns-server". Pudimos resolver nuestro problema proporcionando una dirección IP de servidor DNS falsa a través de DHCP, y todos los dispositivos Apple afectados se comunican ahora con direcciones no locales como se esperaba, y la bandera "I" está ahora ausente de la entrada de ruta por defecto.

(Decidimos no tener DNS en este entorno porque no es necesario para nuestra aplicación (todas las configuraciones se autogeneran a partir de una herramienta de planificación común, por lo que no hay ningún beneficio inherente al uso de nombres de host), y hemos tenido experiencia con algunos programas como los servidores web que, en el curso del registro de las solicitudes de los clientes, tratarían de revertir las IPs de nuevo a los nombres de host. Se atascaban debido a las altas tasas de consultas DNS a servidores DNS inexistentes, cada una de las cuales tardaba uno o dos segundos en agotarse. Dado que no había una respuesta negativa, los registros provocarían al menos una consulta que tendría que agotarse. Creemos que es más seguro eliminar la configuración de DNS que identificar cada posible pieza de software que pueda actuar de esta manera).

Así que ahora mismo hemos reconfigurado el pool de DHCP son proporcionar como servidor DNS la dirección IP de un sistema que está en la red pero que no ejecuta un servicio DNS. Está proporcionando mensajes ICMP de puerto inalcanzable, que hasta ahora parece estar evitando el retraso debido al tiempo de espera, pero seguimos preocupados porque nuestras pruebas no descubren todos los posibles casos de error que este cambio de configuración puede causar. Así que si no encontramos una solución mejor a este problema de Apple, puede que tengamos que ejecutar un servicio DNS que no contenga datos, sólo para dar respuestas negativas y evitar la posibilidad de tiempos de espera de DNS.

También podemos intentar segregar los productos Apple para que reciban la configuración DHCP de un grupo diferente, de modo que sólo ellos reciban las opciones del servidor DNS. Creo que hay una manera de identificar los productos Apple basados en OUI, aunque nunca lo he intentado antes.

Espero que alguien tenga una solución mejor que no requiera ningún tipo de cambio en la infraestructura de la red.

Respondido el 30 de Octubre, 2019 por Jeremy Impson (13 Puntos )

Preguntas relacionadas

Preguntas Destacadas

Etiquetas mas usadas

En nuestra red

AppleAyuda.com

AppleAyuda es una comunidad de usuarios de los productos de Apple en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

Yandex
X