[opensuse-es] SFW2-INext-DROP-DEFLT IN....
Feb 17 17:30:16 quijote kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:23:54:07:d0:c2:70:2e:22:e8:90:0f:08:00 SRC=192.168.1.1 DST=192.168.1.155 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=50710 DPT=137 LEN=58 Hoy he abierto una shell y como root he tecleado el comando "journalctl --follow" y ese es el mensaje que se repite constantemente A que hace referencia, que quiere decir, es que hay algo mal??? Gracias.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2018-02-17 a las 17:36 +0100, Nacho escribió:
Feb 17 17:30:16 quijote kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:23:54:07:d0:c2:70:2e:22:e8:90:0f:08:00 SRC=192.168.1.1 DST=192.168.1.155 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=50710 DPT=137 LEN=58
Hoy he abierto una shell y como root he tecleado el comando "journalctl --follow" y ese es el mensaje que se repite constantemente
A que hace referencia, que quiere decir, es que hay algo mal???
Es tu router. Paquete enviado desde 192.168.1.1 a 192.168.1.155 al puerto 137/UDP, rechazado por regla por defecto del cortafuegos (drop-dflt), en red externa (INext). No tiene importancia, salvo que el router trata de averiguar algo sobre tu ordenador y no puede. cer@Telcontar:~> grep " 137/" /etc/services netbios-ns 137/tcp # NETBIOS Name Service netbios-ns 137/udp # NETBIOS Name Service cer@Telcontar:~> O sea, red tipo Windows de toda la vida. Puedes decidir abrir ese puerto, a esa máquina o a todas. Yo lo haría (a esa máquina). - -- Saludos Carlos E. R. (desde openSUSE 42.3 x86_64 "Malachite" en Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlqIcigACgkQtTMYHG2NR9WkWQCdEdRsRZk4oeAhWFCV9IgppYQm x30An2txdKtedi3wD1YOZT8gq1Wty0fF =Ay+/ -----END PGP SIGNATURE-----
A mi tambien me sale lo mismo quijote:/home/nacho # grep " 137/" /etc/services netbios-ns 137/tcp # NETBIOS Name Service netbios-ns 137/udp # NETBIOS Name Service Es curioso lo que dices, yo no tengo nada windows en esta maquina, por que querrá mandar nada a windows si windows no esta.... Aun así lo abrirías?? Gracias. El 17/02/18 a las 19:19, Carlos E. R. escribió:
El 2018-02-17 a las 17:36 +0100, Nacho escribió:
Feb 17 17:30:16 quijote kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:23:54:07:d0:c2:70:2e:22:e8:90:0f:08:00 SRC=192.168.1.1 DST=192.168.1.155 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=50710 DPT=137 LEN=58
Hoy he abierto una shell y como root he tecleado el comando "journalctl --follow" y ese es el mensaje que se repite constantemente
A que hace referencia, que quiere decir, es que hay algo mal???
Es tu router.
Paquete enviado desde 192.168.1.1 a 192.168.1.155 al puerto 137/UDP, rechazado por regla por defecto del cortafuegos (drop-dflt), en red externa (INext).
No tiene importancia, salvo que el router trata de averiguar algo sobre tu ordenador y no puede.
cer@Telcontar:~> grep " 137/" /etc/services netbios-ns 137/tcp # NETBIOS Name Service netbios-ns 137/udp # NETBIOS Name Service cer@Telcontar:~>
O sea, red tipo Windows de toda la vida.
Puedes decidir abrir ese puerto, a esa máquina o a todas. Yo lo haría (a esa máquina).
-- Saludos Carlos E. R. (desde openSUSE 42.3 x86_64 "Malachite" en Telcontar)
On 2018-02-17 19:28, Nacho wrote:
A mi tambien me sale lo mismo
quijote:/home/nacho # grep " 137/" /etc/services netbios-ns 137/tcp # NETBIOS Name Service netbios-ns 137/udp # NETBIOS Name Service
Claro que sale lo mismo. Si saliera otra cosa me mosquearía mucho ;-p
Es curioso lo que dices, yo no tengo nada windows en esta maquina, por que querrá mandar nada a windows si windows no esta.... Aun así lo abrirías??
Pero el router no sabe que no tienes Windows. Está tratando de averiguar el nombre de la máquina para ponerlo en el listado de máquinas, creo. Da por supuesto que será Windows (quien leches va a poner esa m*a de Linux? Ni preguntamos) por lo que intenta conectar con ese puerto. Juás :-)) -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Bueno, entonces sigues pensando que seria bueno abrir ese puerto en el firewall.... Mejor dicho, esos puertos 137 udp/tcp De esto como de casi todo, se poco, en la zona interna, externa o dmz..... Supongo que como viene de fuera sera en la externa.... Correcto? Gracias. El 17/02/18 a las 20:49, Carlos E. R. escribió:
On 2018-02-17 19:28, Nacho wrote:
A mi tambien me sale lo mismo
quijote:/home/nacho # grep " 137/" /etc/services netbios-ns 137/tcp # NETBIOS Name Service netbios-ns 137/udp # NETBIOS Name Service
Claro que sale lo mismo. Si saliera otra cosa me mosquearía mucho ;-p
Es curioso lo que dices, yo no tengo nada windows en esta maquina, por que querrá mandar nada a windows si windows no esta.... Aun así lo abrirías??
Pero el router no sabe que no tienes Windows. Está tratando de averiguar el nombre de la máquina para ponerlo en el listado de máquinas, creo. Da por supuesto que será Windows (quien leches va a poner esa m*a de Linux? Ni preguntamos) por lo que intenta conectar con ese puerto.
Juás :-))
-- openSUSE Leap 42.2 Versión de KDE Plasma 5.8.3 Versión del Kernel 4.4.46-11-default Procesador: 4xIntel Core 2 Quad CPU Q8200@ 2.33 GHZ Memoria 3,9 GiB de RAM Tarjeta Grafica NVIDIA GeForce 9600 GT/PCIe/SSE2
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2018-02-17 at 22:44 +0100, Nacho wrote:
Bueno, entonces sigues pensando que seria bueno abrir ese puerto en el firewall.... Mejor dicho, esos puertos 137 udp/tcp De esto como de casi todo, se poco, en la zona interna, externa o dmz.....
Supongo que como viene de fuera sera en la externa.... Correcto?
Sugerencia: FW_TRUSTED_NETS="192.168.1.1,udp,netbios-ns" Eso le da acceso exclusivamente a esa IP de origen. Es posible que al abrirlo aparezcan paquetes desde el router en otros puertos, ya se vería. Yo también tengo: FW_SERVICES_ACCEPT_RELATED_EXT="192.168.1.0/24,udp,137" pero creo que no lo necesitas - salvo que te aparezcan otras conexiones relacionadas. En este caso yo abrí a toda la red local, pero se puede restringir a una sola máquina. - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlqIq2oACgkQtTMYHG2NR9X5UgCdG2hYT306QspODmnrpfSy6/cN KWAAn1SrTBBQOju0+l1dsgT5tTKwuKu8 =vG1q -----END PGP SIGNATURE-----
Bueno, pues he añadido esa linea tal y como tu la has puesto en la sugerencia y sigue saliendo lo mismo. Ahora voy a probar con la segunda linea, a ver que pasa. Y sigue pasando lo mismo, entiendo que estas lineas son las de: /etc/sysconfig/SuSEfirewall2??? El 17/02/18 a las 23:23, Carlos E. R. escribió:
On Saturday, 2018-02-17 at 22:44 +0100, Nacho wrote:
Bueno, entonces sigues pensando que seria bueno abrir ese puerto en el firewall.... Mejor dicho, esos puertos 137 udp/tcp De esto como de casi todo, se poco, en la zona interna, externa o dmz.....
Supongo que como viene de fuera sera en la externa.... Correcto?
Sugerencia:
FW_TRUSTED_NETS="192.168.1.1,udp,netbios-ns"
Eso le da acceso exclusivamente a esa IP de origen. Es posible que al abrirlo aparezcan paquetes desde el router en otros puertos, ya se vería.
Yo también tengo:
FW_SERVICES_ACCEPT_RELATED_EXT="192.168.1.0/24,udp,137"
pero creo que no lo necesitas - salvo que te aparezcan otras conexiones relacionadas. En este caso yo abrí a toda la red local, pero se puede restringir a una sola máquina.
-- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar)
-- openSUSE Leap 42.2 Versión de KDE Plasma 5.8.3 Versión del Kernel 4.4.46-11-default Procesador: 4xIntel Core 2 Quad CPU Q8200@ 2.33 GHZ Memoria 3,9 GiB de RAM Tarjeta Grafica NVIDIA GeForce 9600 GT/PCIe/SSE2
On 2018-02-18 11:47, Nacho wrote:
Bueno, pues he añadido esa linea tal y como tu la has puesto en la sugerencia y sigue saliendo lo mismo.
Ahora voy a probar con la segunda linea, a ver que pasa.
Y sigue pasando lo mismo, entiendo que estas lineas son las de:
/etc/sysconfig/SuSEfirewall2???
Si. Te has acordado de decirle que las cargue? SuSEfirewall2 en un terminal como root. Por cierto, las lineas no hay que añadirlas, ya existen. Hay que buscarlas en el fichero y cambiarlas ligeramente. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Que no quiere, lo he hecho como tu dices, modificando las lineas, detuve el cortafuegos y lo reinicie, ahora le he dicho que cargue las reglas pero sigue igual.... El 18/02/18 a las 12:14, Carlos E. R. escribió:
On 2018-02-18 11:47, Nacho wrote:
Bueno, pues he añadido esa linea tal y como tu la has puesto en la sugerencia y sigue saliendo lo mismo.
Ahora voy a probar con la segunda linea, a ver que pasa.
Y sigue pasando lo mismo, entiendo que estas lineas son las de:
/etc/sysconfig/SuSEfirewall2???
Si. Te has acordado de decirle que las cargue?
SuSEfirewall2
en un terminal como root.
Por cierto, las lineas no hay que añadirlas, ya existen. Hay que buscarlas en el fichero y cambiarlas ligeramente.
-- openSUSE Leap 42.2 Versión de KDE Plasma 5.8.3 Versión del Kernel 4.4.46-11-default Procesador: 4xIntel Core 2 Quad CPU Q8200@ 2.33 GHZ Memoria 3,9 GiB de RAM Tarjeta Grafica NVIDIA GeForce 9600 GT/PCIe/SSE2
mirando mirando, ahora ha cambiado.... hay lineas nuevas..... ah, pero estas son generadas por los paquetes que llegan con el amule, que ahora esta encendido, como estas: Feb 18 18:30:06 quijote kernel: SFW2-INext-ACC-TCP IN=eth0 OUT= MAC=00:23:54:07:d0:c2:70:2e:22:e8:90:0f:08:00 SRC=95.122.21.86 DST=192.168.1.155 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=53058 DF PROTO=TCP SPT=58199 DPT=4662 WINDOW=14600 RES=0x00 SYN URGP=0 OPT (020405AC0402080A05338B690000000001030307) llegan a través a través del puerto 4662 que es de amule. ... pero Feb 18 18:41:37 quijote kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:23:54:07:d0:c2:70:2e:22:e8:90:0f:08:00 SRC=188.127.185.201 DST=192.168.1.155 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=4665 DPT=137 LEN=58 El 18/02/18 a las 12:14, Carlos E. R. escribió:
On 2018-02-18 11:47, Nacho wrote:
Bueno, pues he añadido esa linea tal y como tu la has puesto en la sugerencia y sigue saliendo lo mismo.
Ahora voy a probar con la segunda linea, a ver que pasa.
Y sigue pasando lo mismo, entiendo que estas lineas son las de:
/etc/sysconfig/SuSEfirewall2???
Si. Te has acordado de decirle que las cargue?
SuSEfirewall2
en un terminal como root.
Por cierto, las lineas no hay que añadirlas, ya existen. Hay que buscarlas en el fichero y cambiarlas ligeramente.
-- openSUSE Leap 42.2 Versión de KDE Plasma 5.8.3 Versión del Kernel 4.4.46-11-default Procesador: 4xIntel Core 2 Quad CPU Q8200@ 2.33 GHZ Memoria 3,9 GiB de RAM Tarjeta Grafica NVIDIA GeForce 9600 GT/PCIe/SSE2
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2018-02-18 a las 18:44 +0100, Nacho escribió:
mirando mirando, ahora ha cambiado.... hay lineas nuevas..... ah, pero estas son generadas por los paquetes que llegan con el amule, que ahora esta encendido, como estas:
Feb 18 18:30:06 quijote kernel: SFW2-INext-ACC-TCP IN=eth0 OUT= MAC=00:23:54:07:d0:c2:70:2e:22:e8:90:0f:08:00 SRC=95.122.21.86 DST=192.168.1.155 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=53058 DF PROTO=TCP SPT=58199 DPT=4662 WINDOW=14600 RES=0x00 SYN URGP=0 OPT (020405AC0402080A05338B690000000001030307)
llegan a través a través del puerto 4662 que es de amule.
Pero en este caso te dice que el paquete ha sido aceptado: SFW2-INext-ACC-TCP ...........^^^
... pero
Feb 18 18:41:37 quijote kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:23:54:07:d0:c2:70:2e:22:e8:90:0f:08:00 SRC=188.127.185.201 DST=192.168.1.155 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=4665 DPT=137 LEN=58
Este es extraño, está rechazando 137 UDP que dices lo has puesto en el cortafuegos. Ah, ¡espera! Fíjate en el "source": SRC=188.127.185.201 Es una IP en internet, no es de tu red local. Lo correcto es rechazarlo. Y más extraño, te pone la MAC originante, por lo que está en tu segmento de red. ¿Que tipo de conexión a Internet tienes? ¿Yoigo quizás? - -- Saludos Carlos E. R. (desde openSUSE 42.3 x86_64 "Malachite" en Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlqJxugACgkQtTMYHG2NR9VXxQCfXUTMAhtHGZTzA56Q93yCWfS5 3HsAn342JHt6KU/9E4xTyAEZFEzz5kGr =/YJR -----END PGP SIGNATURE-----
Si yoigo, que ocurre... El 18/02/18 a las 19:33, Carlos E. R. escribió:
El 2018-02-18 a las 18:44 +0100, Nacho escribió:
mirando mirando, ahora ha cambiado.... hay lineas nuevas..... ah, pero estas son generadas por los paquetes que llegan con el amule, que ahora esta encendido, como estas:
Feb 18 18:30:06 quijote kernel: SFW2-INext-ACC-TCP IN=eth0 OUT= MAC=00:23:54:07:d0:c2:70:2e:22:e8:90:0f:08:00 SRC=95.122.21.86 DST=192.168.1.155 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=53058 DF PROTO=TCP SPT=58199 DPT=4662 WINDOW=14600 RES=0x00 SYN URGP=0 OPT (020405AC0402080A05338B690000000001030307)
llegan a través a través del puerto 4662 que es de amule.
Pero en este caso te dice que el paquete ha sido aceptado:
SFW2-INext-ACC-TCP ...........^^^
... pero
Feb 18 18:41:37 quijote kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:23:54:07:d0:c2:70:2e:22:e8:90:0f:08:00 SRC=188.127.185.201 DST=192.168.1.155 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=4665 DPT=137 LEN=58
Este es extraño, está rechazando 137 UDP que dices lo has puesto en el cortafuegos. Ah, ¡espera! Fíjate en el "source":
SRC=188.127.185.201
Es una IP en internet, no es de tu red local. Lo correcto es rechazarlo.
Y más extraño, te pone la MAC originante, por lo que está en tu segmento de red.
¿Que tipo de conexión a Internet tienes? ¿Yoigo quizás?
-- Saludos Carlos E. R. (desde openSUSE 42.3 x86_64 "Malachite" en Telcontar)
-- openSUSE Leap 42.2 Versión de KDE Plasma 5.8.3 Versión del Kernel 4.4.46-11-default Procesador: 4xIntel Core 2 Quad CPU Q8200@ 2.33 GHZ Memoria 3,9 GiB de RAM Tarjeta Grafica NVIDIA GeForce 9600 GT/PCIe/SSE2
On 2018-02-18 20:23, Nacho wrote:
Si yoigo, que ocurre...
:-) Acerté. Que la IP que te entra también es de Yoigo. Mi hipótesis es que estáis varios o muchos clientes en el mismo segmento de red, y tu router no tiene un cortafuegos activo, por lo que te entran desde fuera. A falta de cortafuegos en el router, tienes que tenerlo en todos tus ordenadores y teléfonos y todo. El de openSUSE simplemente te dice lo que está haciendo. Otros proveedores, otros países... cortan el puerto 137. Mira en la configuración del router a ver si puedes levantar el cortafuegos. Si es que lo tiene. Hay sitios con instrucciones. Ahora me tengo que ir. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Bueno, decirte que yoigo no se que sistema sigue que tiene a sus clientes tras cgnat, que no se muy bien que es eso, y si quieres que ciertas aplicaciones te funcionen tienes que pedirles que te asignen IP pública y te saquen de "CGNAT" (que diablos sera esto) Y luego entrando en la configuración del router, si que tiene un cortafuegos y esta activo, pero tiene tres niveles Instruction of firewall level(IPv4): High: Allow legal WAN side access, but prohibit Ping from WAN side. Middle: Allow legal WAN side access and resist certain types of dangerous data travelling over the Internet. Low: Allow legal WAN side access and Ping from WAN side. Ahora mismo tiene activado el LOW, pero desconozco que nivel le debería poner..... Eso si, para IPv6 no he visto nada. Gracias. El 18/02/18 a las 20:45, Carlos E. R. escribió:
On 2018-02-18 20:23, Nacho wrote:
Si yoigo, que ocurre...
:-)
Acerté.
Que la IP que te entra también es de Yoigo.
Mi hipótesis es que estáis varios o muchos clientes en el mismo segmento de red, y tu router no tiene un cortafuegos activo, por lo que te entran desde fuera. A falta de cortafuegos en el router, tienes que tenerlo en todos tus ordenadores y teléfonos y todo. El de openSUSE simplemente te dice lo que está haciendo.
Otros proveedores, otros países... cortan el puerto 137.
Mira en la configuración del router a ver si puedes levantar el cortafuegos. Si es que lo tiene. Hay sitios con instrucciones.
Ahora me tengo que ir.
On 2018-02-18 21:38, Nacho wrote:
Bueno, decirte que yoigo no se que sistema sigue que tiene a sus clientes tras cgnat, que no se muy bien que es eso, y si quieres que ciertas aplicaciones te funcionen tienes que pedirles que te asignen IP pública y te saquen de "CGNAT" (que diablos sera esto)
Creo que adivino lo que es. Un momento que lo miro. [...] Sí, es lo que pensaba: https://en.wikipedia.org/wiki/Carrier-grade_NAT https://es.wikipedia.org/wiki/Carrier_Grade_NAT Una mierda pinchada en un palo, eso es lo que es. Wikipedia: +++.-.-.-.-.-.- *Carrier Grade NAT* El NAT masivo, conocido también como NAT a gran escala (Large-Scale NAT, o LSN) o Carrier-Grade NAT (CGN o CG-NAT), es una herramienta de diseño de redes IPv4 donde los extremos de la comunicación, en concreto, las redes residenciales, se configuran con direcciones de red privadas, que se traducen a direcciones públicas mediante equipos de traducción que se interponen dentro de la red del proveedor entre el usuario e Internet. Estos dispositivos permiten compartir conjuntos pequeños de direcciones públicas entre muchos puntos finales. Esto cambia el lugar tradicional donde se hace y se configura la función de NAT desde el equipo de casa del cliente, hacia la red del proveedor de acceso a Internet. Está previsto utilizar CGN masivo como disfunción, con el fin de mitigar el agotamiento de direcciones y uso de IPv4.1 *Desventajas* Sus críticos le encuentran los siguientes desventajas: Como cualquier forma de NAT, rompe el principio de comunicación extremo a extremo.2 Tiene problemas relevantes de seguridad, escalabilidad y fiabilidad, por el hecho de tener que mantener información de estado. Hace imposible el seguimiento y grabacion a los cuerpos de seguridad, a menos que el contenido de la comunicacion sea registrado. Hace imposible el uso de aplicaciones que requieren puertos específicos (instalar un servidor web, por ejemplo). .-.-.-.-.-.-++- A ver, es pura y simplemente NAT, aplicado por el proveedor. No tienen suficientes IPs públicas, por lo que le dan a sus clientes una IP privada. Los agrupan y montones de clientes salen por un gateway, una IP pública común para todos. Por tanto es imposible usar aplicaciones peer-to-peer con Internet, o cualquier tipo de servidor. Impide la telefonía por internet, etc (salvo algunos tipos y trampas). La verdadera solución es usar IPv6 de una puñetera vez. Telefónica usa CG-NAT en los móviles, no en los fijos.
Y luego entrando en la configuración del router, si que tiene un cortafuegos y esta activo, pero tiene tres niveles
Instruction of firewall level(IPv4): High: Allow legal WAN side access, but prohibit Ping from WAN side. Middle: Allow legal WAN side access and resist certain types of dangerous data travelling over the Internet. Low: Allow legal WAN side access and Ping from WAN side.
Vaya caca.
Ahora mismo tiene activado el LOW, pero desconozco que nivel le debería poner..... Eso si, para IPv6 no he visto nada.
Bueno, pues con esas especificaciones tan... tan buenas y claras déjalo como está, puesto que usas el emule. No tienes otra. A no ser que ese router tenga algún tipo de modo avanzado que esté oculto. En el caso del problema que nos ocupa, el problema es la caca de router, que no tiene un cortafuegos decente. Tienes que tener cortafuegos en todas tus máquinas. No pongas Windows, estaría expuesto. Tienes una solución, claro, que es poner un segundo router tuyo. Dos maneras: reemplazar el de Yoigo, o encadenarlos.
Gracias.
De nada :-) -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
En definitiva y como siempre en este país, que te estan vendiendo lo que no te pueden servir y tienen que poner "ñapas" para arreglarlo, ñapas que no lo arreglan como debieran y asi generamos otro problema, pero como este se lo generamos a los clientes, pues mientras no se den cuenta de lo que les hemos vendido y no les moleste que se aguanten....y si se quejan pues a esos si les damos lo que quieren.... Por ahi he leido, que te sacan durante un tiempo de CGNat, pero que si te descuidas te vuelven a poner, los muy "bribones"... A mi que lo he solicatado me han sacado de cgnat y me han asignado una IP pública, ahora el emule anda mejor. Carlos, gracias por tu tiempo y tus explicaciones. Una ultima pregunta, dejo las modificaciones que me aconsejaste en el firewall de opensuse o las revierto, no se si ahora tienen sentido. El 19/02/18 a las 10:49, Carlos E. R. escribió:
On 2018-02-18 21:38, Nacho wrote:
Bueno, decirte que yoigo no se que sistema sigue que tiene a sus clientes tras cgnat, que no se muy bien que es eso, y si quieres que ciertas aplicaciones te funcionen tienes que pedirles que te asignen IP pública y te saquen de "CGNAT" (que diablos sera esto)
Creo que adivino lo que es. Un momento que lo miro. [...] Sí, es lo que pensaba:
https://en.wikipedia.org/wiki/Carrier-grade_NAT https://es.wikipedia.org/wiki/Carrier_Grade_NAT
Una mierda pinchada en un palo, eso es lo que es.
Wikipedia:
+++.-.-.-.-.-.- *Carrier Grade NAT*
El NAT masivo, conocido también como NAT a gran escala (Large-Scale NAT, o LSN) o Carrier-Grade NAT (CGN o CG-NAT), es una herramienta de diseño de redes IPv4 donde los extremos de la comunicación, en concreto, las redes residenciales, se configuran con direcciones de red privadas, que se traducen a direcciones públicas mediante equipos de traducción que se interponen dentro de la red del proveedor entre el usuario e Internet. Estos dispositivos permiten compartir conjuntos pequeños de direcciones públicas entre muchos puntos finales. Esto cambia el lugar tradicional donde se hace y se configura la función de NAT desde el equipo de casa del cliente, hacia la red del proveedor de acceso a Internet.
Está previsto utilizar CGN masivo como disfunción, con el fin de mitigar el agotamiento de direcciones y uso de IPv4.1
*Desventajas*
Sus críticos le encuentran los siguientes desventajas:
Como cualquier forma de NAT, rompe el principio de comunicación extremo a extremo.2 Tiene problemas relevantes de seguridad, escalabilidad y fiabilidad, por el hecho de tener que mantener información de estado. Hace imposible el seguimiento y grabacion a los cuerpos de seguridad, a menos que el contenido de la comunicacion sea registrado. Hace imposible el uso de aplicaciones que requieren puertos específicos (instalar un servidor web, por ejemplo).
.-.-.-.-.-.-++-
A ver, es pura y simplemente NAT, aplicado por el proveedor. No tienen suficientes IPs públicas, por lo que le dan a sus clientes una IP privada. Los agrupan y montones de clientes salen por un gateway, una IP pública común para todos. Por tanto es imposible usar aplicaciones peer-to-peer con Internet, o cualquier tipo de servidor. Impide la telefonía por internet, etc (salvo algunos tipos y trampas).
La verdadera solución es usar IPv6 de una puñetera vez.
Telefónica usa CG-NAT en los móviles, no en los fijos.
Y luego entrando en la configuración del router, si que tiene un cortafuegos y esta activo, pero tiene tres niveles
Instruction of firewall level(IPv4): High: Allow legal WAN side access, but prohibit Ping from WAN side. Middle: Allow legal WAN side access and resist certain types of dangerous data travelling over the Internet. Low: Allow legal WAN side access and Ping from WAN side.
Vaya caca.
Ahora mismo tiene activado el LOW, pero desconozco que nivel le debería poner..... Eso si, para IPv6 no he visto nada.
Bueno, pues con esas especificaciones tan... tan buenas y claras déjalo como está, puesto que usas el emule. No tienes otra.
A no ser que ese router tenga algún tipo de modo avanzado que esté oculto.
En el caso del problema que nos ocupa, el problema es la caca de router, que no tiene un cortafuegos decente.
Tienes que tener cortafuegos en todas tus máquinas. No pongas Windows, estaría expuesto.
Tienes una solución, claro, que es poner un segundo router tuyo. Dos maneras: reemplazar el de Yoigo, o encadenarlos.
Gracias.
De nada :-)
-- openSUSE Leap 42.2 Versión de KDE Plasma 5.8.3 Versión del Kernel 4.4.46-11-default Procesador: 4xIntel Core 2 Quad CPU Q8200@ 2.33 GHZ Memoria 3,9 GiB de RAM Tarjeta Grafica NVIDIA GeForce 9600 GT/PCIe/SSE2
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2018-02-19 a las 16:02 +0100, Nacho escribió:
En definitiva y como siempre en este país, que te estan vendiendo lo que no te pueden servir y tienen que poner "ñapas" para arreglarlo, ñapas que no lo arreglan como debieran y asi generamos otro problema, pero como este se lo generamos a los clientes, pues mientras no se den cuenta de lo que les hemos vendido y no les moleste que se aguanten....y si se quejan pues a esos si les damos lo que quieren....
Por ahi he leido, que te sacan durante un tiempo de CGNat, pero que si te descuidas te vuelven a poner, los muy "bribones"...
Es posible.
A mi que lo he solicatado me han sacado de cgnat y me han asignado una IP pública, ahora el emule anda mejor.
Los proveedores baratos tienen que recortar gastos por algún sitio... Ojo, que a mi telefonica me lo hace en el movil: lo noto/sufro cuando conecto el portatil a través del movil, y gugle me bloquea la bajada de correo porque cree que estoy en Malaga en vez de en Murcia. Es decir, me da una IP en el rango 10.*.*.*, y sale al exterior por una que está asignada a Málaga. A los que estamos por fibra no nos lo hace, y creo que por adsl tampoco. Los móviles, como se supone que no somos ordenadores, pues se supone que no nos enteramos. La solución real es pasarse de una puñetera vez a IPv6, que no entiendo a que esperan. Siempre pueden usar la doble red, IPv6 con tunel a IPv4. Y claro, también, hacerlo todos los españoles el mismo dia.
Carlos, gracias por tu tiempo y tus explicaciones.
De nada :-)
Una ultima pregunta, dejo las modificaciones que me aconsejaste en el firewall de opensuse o las revierto, no se si ahora tienen sentido.
Te lo iba a comentar y se me olvidó; lo pensé después. No lo se, pero me entran dudas de si conservarlo o no. Si el router está bien hecho (dentro de la mala idea), pues no pasa nada; ver el nombre del ordenador desde otros es una ayuda. Pero si está mal hecho igual no es confiable porque le da esos datos a la gente de la red externa. No lo creo pero me pongo en modo paranoico y... De todos, sólo le abre acceso al router, la regla que te dije es restrictiva. - -- Saludos Carlos E. R. (usando openSUSE 42.3 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlqLFd4ACgkQja8UbcUWM1zVFAEAiDqHfQwtOpN5lEOJj/Kpta3G x1okS/hFfoZQsJlwpy8A/0ZA+eB2m+GPTqrQndGgj0cnx8DcXbi83BREYDfRk0Cu =szCS -----END PGP SIGNATURE-----
participants (2)
-
Carlos E. R. -
Nacho