El uso compartido de Internet de WiFi a Ethernet no funciona en Mountain Lion

4

Después de actualizar de Lion a Mountain Lion, parece que la conexión a Internet ya no funciona.

Con la configuración:

  • Compartir red desde: WiFi
  • A las computadoras que usan: Ethernet

Cuando Internet está habilitado, el host no puede acceder a Internet, y tampoco los clientes conectados. Los clientes reciben una dirección IP a través de DHCP, y la ruta correcta está configurada, pero eso es todo.

Parece que el host no puede acceder a Internet porque el dispositivo bridge0 está configurado como la ruta predeterminada:

# Before enabling internet sharing
$ route -n get default
   route to: default
destination: default
       mask: default
    gateway: 192.168.1.1
  interface: en1
      flags: 
 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
       0         0         0         0         0         0      1500         0 
$ ping 4.2.2.1
PING 4.2.2.1 (4.2.2.1): 56 data bytes
64 bytes from 4.2.2.1: icmp_seq=0 ttl=54 time=33.418 ms
…

# And after enabling internet sharing
$ route -n get default
   route to: default
destination: default
       mask: default
  interface: bridge0
      flags: 
 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
       0         0         0         0         0         0      1500        -1 
$ ping 4.2.2.1
PING 4.2.2.1 (4.2.2.1): 56 data bytes
ping: sendto: Host is down
Request timeout for icmp_seq 0
…

Además, deshabilitar el uso compartido de Internet deja la tabla de enrutamiento rota. Tengo que volver a agregar manualmente la ruta predeterminada antes de que las cosas vuelvan a funcionar:

# After disabling internet sharing
$ route -n get default
route: writing to routing socket: not in table
$ ping 4.2.2.1
PING 4.2.2.1 (4.2.2.1): 56 data bytes
ping: sendto: Host is down
Request timeout for icmp_seq 0
…
$ route -n add default 192.168.1.1
$ ping 4.2.2.1
PING 4.2.2.1 (4.2.2.1): 56 data bytes
64 bytes from 4.2.2.1: icmp_seq=0 ttl=54 time=33.418 ms
…

Finalmente, la verificación de la salida de pfctl antes y después de habilitar el uso compartido de Internet no muestra ningún cambio (significativo). ¿Debería haber?

Y varios bits de información:

  • Esto es con OS X 10.8.2
  • La salida de ifconfig cuando se comparte está habilitada (con los adaptadores irrelevantes p2p0 , fw0 , gif0 y stf0 eliminados):
lo0: flags=8049 mtu 16384
    options=3
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
    inet 127.0.0.1 netmask 0xff000000 
    inet6 ::1 prefixlen 128 
en1: flags=8863 mtu 1500
    ether 60:c5:47:93:47:66 
    inet6 fe80::62c5:47ff:fe93:4766%en1 prefixlen 64 scopeid 0x5 
    inet 192.168.1.118 netmask 0xffffff00 broadcast 192.168.1.255
    media: autoselect
    status: active
en0: flags=8963 mtu 1500
    options=2b
    ether 3c:07:54:1a:83:89 
    media: autoselect (none)
    status: inactive
bridge0: flags=8863 mtu 1500
    ether ac:de:48:11:fa:4e 
    inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255
    Configuration:
        priority 0 hellotime 0 fwddelay 0 maxage 0
        ipfilter disabled flags 0x2
    member: en0 flags=3
             port 7 priority 0 path cost 0
    
pregunta David Wolever 01.12.2012 - 22:33

2 respuestas

4

Esto es bastante roto en Mountain Lion. Una vez que haya arreglado la ruta predeterminada como se describe en la pregunta, aún se queda con el problema de que Mountain Lion está dando su dirección de interfaz de puente a los clientes como la dirección del enrutador (que es correcta) y como el servidor DNS dirección (que no lo es).

Verifique que este sea el problema al ingresar una dirección IP del servidor HTTP en la barra de direcciones en un navegador web del cliente cuando se conecte a través de su Mac después de corregir las rutas predeterminadas, y debería cargarse bien.

Mi solución a este problema es arreglar la ruta a medida que se describe, que podría ser automatizada, por supuesto, y mantener BIND (también conocido como / usr / sbin / named) ejecutándose en segundo plano en mi Mac en una configuración de solo reenvío, reenviando todas las consultas a los servidores DNS públicos de Google. Esto no soluciona los problemas subyacentes en Mountain Lion, pero hace que las cosas empiecen a funcionar para los clientes.

Un par de recursos útiles:

enlace (cómo encender BIND en el SO X)

enlace (cómo configurar BIND para operaciones de solo envío, por supuesto que no quiero hacer que BIND solo escuche el 127.0.0.1)

Sería mucho más preferible que Apple hiciera que esta característica de su sistema operativo funcione como se anuncia, pero mientras tanto, me parece que esta es una solución viable.

    
respondido por el Steven Grimm 13.12.2012 - 01:58
3

En realidad, hay un proceso de enlace iniciado después de activar el uso compartido de Internet:

22.12.12 09:21:01,687 named[23072]: starting BIND 9.8.3-P1 -c /etc/com.apple.named.proxy.conf -f

La configuración en /etc/com.apple.named.proxy.conf reenvía las solicitudes dns a servidores DNS razonables.

El problema es que el demonio nombrado no permanece vivo. Hay momentos en que se mantuvo vivo, y todo funciona bien, pero al menos cada dos días no.

    
respondido por el Stefan Ost 22.12.2012 - 10:48

Lea otras preguntas en las etiquetas