Durante los últimos meses, he tenido problemas con cortes regulares de Internet, que afectan a todos los dispositivos de mi red local y me obligan a apagar y encender mi módem por cable. Hoy me di cuenta de que puedo reproducir este problema, o uno similar con los mismos síntomas, instalando un juego con Battle.net de Blizzard.
No se trata sólo de saturar mi ancho de banda, ya que
- la descarga también se detiene,
- también sucede al limitar la velocidad de descarga,
- y no se resuelve automáticamente al pausar la descarga; solo ayuda reiniciar el módem.
Para ver exactamente cuándo falla mi conexión a Internet, estoy ejecutando un simple ping 8.8.8.8en una computadora portátil Linux separada (estoy usando Arch por cierto) conectada a la misma red, pero aún puedo continuar haciendo ping, ¡incluso cuando falla mi conexión a Internet! Sólo al detener la carrera.silbido, y al reiniciarlo, ya no obtengo ninguna respuesta.
Estoy un poco desconcertado por este comportamiento. También intenté correr ping 8.8.8.8uno watch -n1 ping -c 1 8.8.8.8al lado del otro, mientras que el correr continuamentesilbidoEl proceso sigue funcionando, elsilbidoproceso reiniciado periódicamente pormirarfalla tan pronto como se corta Internet.
¿Cómo es esto posible? Aparentemente parece que las "sesiones de ping activas" no se ven afectadas por mi interrupción. Pero con ping usando ICMP en la capa 3, no entiendo por qué hay una diferencia entre mantenersilbidocorrer, en lugar de empezar de nuevo.
Después de ver que las descargas de Battle.net también causan este problema, inmediatamente sospeché que algo relacionado con demasiadas conexiones P2P obstruían mi enrutador. Pero tampoco estoy seguro de si Battle.net realmente usa P2P, ni veo nada sospechoso en mi enrutador con respecto a las conexiones activas (~3000 a 4000 conexiones de un máximo de 15,360), uso de memoria o cosas similares.
Desafortunadamente, no puedo ver las métricas de mi módem por cable, ya que mi ISP no proporciona una interfaz adecuada, razón por la cual lo estoy ejecutando en modo puente.
¿Hay alguna explicación para este comportamiento?
Editar: Eché un vistazo a los mensajes ICMP usando Wireshark: la única diferencia notable entre las solicitudes de eco ICMP que obtienen una respuesta y las que no:
- el identificador ICMP está vinculado al proceso; solicitudes de la carrerasilbidotienen la misma identificación, las solicitudes del ping de reinicio obtienen una nueva
- El número de secuencia aumenta con cada solicitud enviada por el sistema en ejecución.silbido, pero se establece en 1 para el que se reinicia
Ese es un comportamiento muy esperado y realmente no me ayuda más; después de todo, ¿por qué esto haría que las solicitudes se trataran de manera diferente?
Respuesta1
¿Cómo es esto posible? Aparentemente parece que las "sesiones de ping activas" no se ven afectadas por mi interrupción. Pero con el ping usando ICMP en la capa 3, no entiendo por qué hay una diferencia entre mantener el ping ejecutándose y comenzar de nuevo.
Incluso para los protocolos que no tienen un estado explícito, como UDP e ICMP Echo, su enrutador aún necesita mantener su propio estado para sus funciones de firewall y NAT. (Por ejemplo, realiza un seguimiento de las asignaciones NAT para saber a qué host interno devolver los paquetes de respuesta de eco). Para dichos protocolos, cualquier primer paquete que envíe establece el estado; un tiempo de espera después de la inactividad hace que se elimine.
Al igual que con TCP, la tabla de estado recuerda los puertos de origen-destino de un flujo de paquetes UDP o el "ID de solicitud" singular de un flujo de eco ICMP. Aunque ICMP no tiene números de puerto, las solicitudes de Echo tienen una identificación que cumple el mismo propósito de distinguir los flujos entre sí. (Si observa una captura de paquetes en Wireshark, verá esto). Es decir, cada nueva pinginvocación provoca que se agregue una nueva entrada de estado.
(Para un ejemplo práctico: si lo hace, conntrack -Lpuede ver los estados rastreados por el firewall iptables/nftables de su computadora, que es básicamente lo mismo que la mayoría de los enrutadores domésticos usan internamente. Tenga en cuenta el idcampo de estados de eco ICMP).
Entonces, según la descripción de su problema, parece que la tabla de estado del enrutador se llena debido a demasiadas "conexiones" y su firmware se configuró para dejar de aceptar nuevos estados, en lugar de permitirles eliminar los antiguos. (Para ser justos, yopensar¿Ese es el comportamiento predeterminado de Linux conntrack?)
También podría ser que el enrutador problemático tenga un error que le impidaclaroestados, y su memoria simplemente se llena hasta que se reinicia; especialmente si el enrutador descarga NAT a la aceleración de hardware y si dicha descarga tiene una eliminación de estado interrumpida. (No me sorprendería en absoluto si ese fuera el caso y el ISP simplemente lo programara para reiniciarse una vez a la semana, lo que sería "suficientemente bueno" para usuarios ocasionales).
Battle.net no usa P2P hoy en día, es sólo HTTP desde una CDN (aunque solía estar basado en BitTorrent hace mucho tiempo), perohaceestablece una cantidad relativamente grande de descargas HTTP paralelas y ciertamente puede contribuir al problema.
Finalmente, como se menciona en los comentarios, esposible(aunque no estoy seguro de que sea probable) que el firewall de su enrutador pierda todos los filtros y/o reglas NAT. Esto tendría sentido para un dispositivo basado en Linux; de hecho, iptables procesa automáticamente NAT para los estados existentes, por lo que si la regla SNAT o MASQUERADE saliente se elimina por algún motivo, impedirá que se realicen nuevas conexiones, pero las existentes seguirán funcionando. (Continuarán teniendo NAT de acuerdo con la información ya almacenada en el estado).
Si no encuentra una manera de resolverlo, una VPN probablemente sea una solución alternativa: todo el túnel VPN cuenta como un solo estado hasta donde su enrutador puede verlo.