4 votos

Compartir Internet desde WiFi a Ethernet no funciona en Mountain Lion

Después de pasar de Lion a Lion de Montaña, parece que compartir Internet ya no funciona.

Con los ajustes:

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

Cuando se habilita el uso compartido de Internet, el anfitrión no puede acceder a Internet, y tampoco los clientes conectados. A los clientes se les da una dirección IP a través de DHCP, y se configura la ruta correcta, pero eso es todo.

Parece que el anfitrión no puede acceder a Internet porque el bridge0 El dispositivo está configurado como la ruta por defecto:

\# 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, al desactivar el Compartir Internet se deja la tabla de enrutamiento rota. Tengo que añadir manualmente la ruta por defecto de nuevo antes de que las cosas empiecen a funcionar de nuevo:

\# 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, comprobando la salida de pfctl antes y después de habilitar el uso compartido de Internet no muestra ningún cambio (significativo). ¿Debería haberlos?

Y varios bits de información:

  • Esto es con OS X 10.8.2
  • La salida de ifconfig cuando se habilita la compartición (con adaptadores irrelevantes p2p0 , fw0 , gif0 y stf0 removido):

    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

4voto

Mave Puntos 126

Esto es, de hecho, bastante roto en Mountain Lion. Una vez que se ha arreglado la ruta por defecto como se describe en la pregunta, todavía queda el problema de que Mountain Lion está dando su dirección de interfaz de puente a los clientes como la dirección del router (que es correcta) y como la dirección del servidor DNS (que no lo es).

Verifica que este es el problema introduciendo una dirección IP del servidor HTTP en la barra de direcciones de un navegador web cliente cuando te conectes a través de tu Mac después de arreglar las rutas por defecto, y debería cargarse bien.

Mi solución a este problema es arreglar la ruta como la describes, que podría ser automatizada, por supuesto, y mantener el BIND (alias /usr/sbin/nombre) ejecutándose en segundo plano en mi Mac en una configuración sólo de avance, reenviando todas las consultas a los servidores públicos de DNS de Google. Esto no arregla la ruptura subyacente en Mountain Lion, pero hace que las cosas empiecen a funcionar para los clientes.

Un par de recursos útiles:

http://www.macshadows.com/kb/index.php?title=How_To:_Enable_BIND_-_Mac_OS_X%27s_Built-in_DNS_Server (cómo encender el BIND en el OS X)

http://gleamynode.net/articles/2267/ (cómo configurar el BIND para que funcione sólo en el futuro por supuesto que no quieren hacer que BIND sólo escuche en 127.0.0.1)

Sería preferible para Apple hacer que esta característica de su sistema operativo funcione como se anuncia, pero mientras tanto he encontrado que es una solución viable.

3voto

Stefan Ost Puntos 31

En realidad, hay un proceso de unión iniciado después de activar el intercambio 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 veces que se mantiene vivo, y todo funciona bien, pero al menos cada dos días no lo hace.

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:

X