Bueno, pues después de mucho tira y afloja, hemos dado con la causa del problema: tenemos un problema de segmentación TCP. Dejadme que os explique esto un poco más en detalle: cuando metemos tráfico por un túnel VPN, el que sea, tenemos que tener en cuenta que el tamaño del paquete que podemos pasar por esa conexión se reduce. ¿Cuánto? Pues depende del tipo de túnel. Pero, siempre, siempre, siempre, va a ser menor a los 1500 bytes del tamaño de segmento TCP que manejamos en local (el famoso MTU). Cuando creamos una interfaz wireguard, el túnel se come 80 bytes de overhead, para mandar datos del propio túnel, dejándonos un tamaño aprovechable de 1420 bytes. Hay tipos de VPN que hacen este cálculo automático, y otras no.
Pues bien, cuando tú te conectas con un móvil como road-warrior a un router MikroTik, la aplicación sabe que por ahí no puede pasar más de 1420 bytes, y, de hacerlo, se producirá fragmentación (se partirá un paquete de 1500 en dos, y se mandarán 1420 de una vez, y los 80 restantes de una segunda vez, con la merma de rendimiento correspondiente). La aplicación, que no es tonta, dice: antes de fragmentar el paquete a la hora de lanzarlo, ya acuerdo yo con quien sea al que me esté conectando que el tamaño máximo de lo que le voy a enviar es menor, y así esto va como un tiro (pasas 80 bytes menos de tráfico en cada tacada, pero haces la mitad de tacadas). Esto también ocurre en los propios routers mikrotik con la regla de ICMP que veis en el chain de input, y que es tremendamente importante (y muchos se empeñan en quitar) par dicho cálculo.
Pero, ¿qué pasas cuando enrutamos dos LAN (o sacamos tráfico a internet vía la IP pública de otro extremo de un túnel VPN) y trabajamos en forward? Pues que ese cálculo, simplemente, no se hace. Y tu red LAN, que trabaja con 1500 bytes, siempre va a intentar ir con ese tamaño a todos sitios, mientras alguien no le diga lo contrario. Y hay servicios que funcionan con fragmentación, y hay otros que simplemente no funcionan. Y esto último es justo lo que te está pasando con DANZ y M+.
Al lío, ¿cómo lo solucionamos? Pues muy sencillo (y mira que me ha costado verlo, aún teniendo delante de mis narices... yo mismo tengo esta regla en mi red): con una regla de mangle que diga: "cuando vengas de este origen y salgas por el túnel, ojo cuidado y primero negocia el MTU que vas a usar. En la misma regla, si conocemos de antemano el MTU, podríamos llegar a establecerlo fijo, pero mejor usar el path discovery del MTU (lo que os contaba antes del ping, tenéis más detalle de cómo funciona
aquí) para hacer dicha negociación y ver que, en el tránsito de A a B, no se puede ir con más de x tamaño de MTU sin producir fragmentación. La regla en cuestión, para el amigo
@soso75, es esta:
Código:
/ip firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu out-interface=\
wg-sts-es src-address=192.168.88.248/29 protocol=tcp \
tcp-flags=syn passthrough=yes
La regla dice, literlamente: cuando mandes un paquete de tipo tcp-sync con origen 192.168.88.248/29 (la subred a enrutar vía España) y destino cualquier cosa al otro lado del túnel, utiliza el cálculo automático del MTU para establecer el tamaño máximo del paquete (clamp-to-pmtu = ajústalo al tamaño del MTU descubierto a lo largo de todo el path desde A hasta B).
Con esto, dicho ajuste se producirá par cada nueva conexión y el resto de paquetes relacionados se enviarán con ese tamaño, haciendo que todo fluya como debe.
En definitiva, una chorrada, pero que te puede volver loco, si no caes en la cuenta. Así que nada, que disfrutes de tus servicios allá donde quieras, que para eso los pagas.
Saludos!
y otra vez vuelvo con dudas...
www.trustedreviews.com
