[eside-ghost] iproute2 y la de siempre... router con 2 salidasainternet

Mar Oct 7 10:16:39 CEST 2008

Buenas eguein!

Bien, lo de las tablas de rutas ya tiene buena pinta por no decir que
funciona (gracias por el enfoque)... ahora el problema está en otro lado...
y aquí sí que empiezo a estar acojonading ;-) (es de expediente X y se
aceptan sugerencias raras :-D )

Os cuento que lo que he montado y perdonad por el html pero es que si no, no
se ve un carajo.

Básicamente esto es un Linux conectado al cablemodem de euskaltel vía
ethernet.

El interfaz pilla dirección ip vía dhcp, y rula guay.

El caso es que como lo que tengo contratado es una ip estática, hay que
establecer un túnel pptp con Euskaltel para que te la asigne y después,
rutar todo el tráfico por ese interfaz.

Vale, todo esto parece funcionar y si meto una máquina mediante reglas de
origen para que su tráfico se enrute por la tabla auxiliar... los pings
salen por donde deben...

Eso sí, no navego ni pa dios.... :-| y ahí es donde la flipo...

Esnifando veo que todos los paquetes de todos los tipos salen por donde
deben y por la otra salida, no sale nada "malo" con lo que doy por supuesto
que las tablas de rutas están bien...

Eso sí, por el interfaz que tiene establecido el pptp, se ve el tráfico que
casca porque faltan bytes en las respuestas... (eso me ha dejado chinado)

09:43:45.455006 IP 83.213.96.190 > 62.99.88.224: gre

09:43:48.248498 IP 83.213.96.190 > 62.99.88.224: GREv1, call 830, seq 121,
length 552: IP truncated-ip - 91 bytes missing! 62.99.71.230.2411 >
77.224.232.248.www: FP 1339631169:1339631756(587) ack 3039543691 win 65535

09:43:48.248531 IP 83.213.96.190 > 62.99.88.224: gre

09:43:50.063326 IP 83.213.96.190 > 62.99.88.224: GREv1, call 830, seq 122,
length 24: LCP, Echo-Request (0x09), id 7, length 10

09:43:50.073191 IP 62.99.88.224 > 83.213.96.190: GREv1, call 55737, seq 97,
ack 122, length 28: LCP, Echo-Reply (0x0a), id 7, length 10

09:43:50.451181 arp who-has 83.213.96.1 tell 83.213.96.190

09:43:50.459907 arp reply 83.213.96.1 is-at 00:0e:83:ca:d9:9d (oui Unknown)

09:43:50.571236 IP 83.213.96.190 > 62.99.88.224: GREv1, call 830, ack 97,
no-payload, length 12

09:43:50.954710 IP 83.213.96.190 > 62.99.88.224: GREv1, call 830, seq 123,
length 552: IP truncated-ip - 292 bytes missing! 62.99.71.230 >
77.224.232.248: ICMP echo request, id 512, seq 18650, length 808

09:43:50.954734 IP 83.213.96.190 > 62.99.88.224: gre

09:43:56.454307 IP 83.213.96.190 > 62.99.88.224: GREv1, call 830, seq 124,
length 552: IP truncated-ip - 292 bytes missing! 62.99.71.230 >
77.224.232.248: ICMP echo request, id 512, seq 18906, length 808

09:43:56.454337 IP 83.213.96.190 > 62.99.88.224: gre

Cuando digo que los pings rulan bien es porque desde el mismo pc que falla
el tema web, he tirao pings de hasta 5000 bytes durante toda la noche y
tienen buena pinta y tirando de esnifer he visto que salen por el interfaz
que deben.

Estadísticas de ping para 77.224.232.248:

    Paquetes: enviados = 47055, recibidos = 47013, perdidos = 42

    (0% perdidos),

Tiempos aproximados de ida y vuelta en milisegundos:

    Mínimo = 166ms, Máximo = 420ms, Media = 177ms

He pensado que era tema de MTU así que he iniciado un Windows, he conectao
el cable modem, he arrancado el pptp y con el win funcionan tanto los pings
como la navegación… y he calculado la mtu para forzarla en el pptp y na…

He probado con otras direcciones ip de destino ;-)…. PERO AQUÍ VIENE EL
DESPIPORRE!!!… :-D Esnifando el ppp0:

09:58:47.094446 IP 62.99.71.230.2428 > 209.85.129.99.www: S
3631408981:3631408981(0) win 65535 <mss 1460,nop,nop,sackOK>

09:58:47.140488 IP 209.85.129.99.www > 62.99.71.230.2428: S
406701305:406701305(0) ack 3631408982 win 5720 <mss 1430,nop,nop,sackOK>

09:58:47.140811 IP 62.99.71.230.2428 > 209.85.129.99.www: . ack 1 win 65535

09:58:47.146672 IP 62.99.71.230.2428 > 209.85.129.99.www: P 1:609(608) ack 1
win 65535

09:58:50.140087 IP 62.99.71.230.2428 > 209.85.129.99.www: P 1:609(608) ack 1
win 65535

09:58:56.174817 IP 62.99.71.230.2428 > 209.85.129.99.www: P 1:609(608) ack 1
win 65535

09:58:57.188270 IP 209.85.129.99.www > 62.99.71.230.2428: F 1:1(0) ack 1 win
5720

09:58:57.188554 IP 62.99.71.230.2428 > 209.85.129.99.www: . ack 2 win 65535

09:58:57.189710 IP 62.99.71.230.2428 > 209.85.129.99.www: F 609:609(0) ack 2
win 65535

09:58:57.239864 IP 209.85.129.99.www > 62.99.71.230.2428: R
406701307:406701307(0) win 0

Ya me lo tomo con humor, pongo música y bailo a lo disco Stúuu

Lo peor… (sin duda alguna) ¿¿¿Porqué IMAPS funciona bien???? Acojonanting…

10:01:54.867770 IP 130.206.100.17.imaps > 62.99.71.230.2434: P 1454:1499(45)
ack 437 win 6432

10:01:54.869581 IP 62.99.71.230.2434 > 130.206.100.17.imaps: P 437:476(39)
ack 1499 win 65535

10:01:54.914104 IP 130.206.100.17.imaps > 62.99.71.230.2434: P
1499:1991(492) ack 476 win 6432

10:01:54.944608 IP 62.99.71.230.2434 > 130.206.100.17.imaps: P 476:536(60)
ack 1991 win 65043

10:01:55.018387 IP 130.206.100.17.imaps > 62.99.71.230.2434: . ack 536 win
6432

10:01:55.125050 IP 130.206.100.17.imaps > 62.99.71.230.2434: P 1991:2077(86)
ack 536 win 6432

10:01:55.129065 IP 62.99.71.230.2434 > 130.206.100.17.imaps: P 536:595(59)
ack 2077 win 64957

10:01:55.162484 IP 130.206.100.17.imaps > 62.99.71.230.2434: . ack 595 win
6432

10:01:55.185738 IP 130.206.100.17.imaps > 62.99.71.230.2434: P 2077:2162(85)
ack 595 win 6432

Tirando del eth3…

10:05:19.049328 IP 83.213.96.190 > 62.99.88.224: GREv1, call 830, seq 684,
ack 571, length 92: IP 62.99.71.230.2414 > 130.206.100.17.imaps: P 59:91(32)
ack 91 win 64297

10:05:19.101291 IP 62.99.88.224 > 83.213.96.190: GREv1, call 55737, seq 572,
ack 684, length 103: IP 130.206.100.17.imaps > 62.99.71.230.2414: P
91:134(43) ack 91 win 6432

10:05:19.113162 IP 62.99.88.224 > 83.213.96.190: GREv1, call 55737, seq 573,
ack 684, length 60: IP 130.206.100.17.imaps > 62.99.71.230.2436: . ack 126
win 6432

10:05:19.211535 IP 62.99.88.224 > 83.213.96.190: GREv1, call 55737, seq 574,
ack 684, length 146: IP 130.206.100.17.imaps > 62.99.71.230.2436: P
538:624(86) ack 126 win 6432

10:05:19.216005 IP 83.213.96.190 > 62.99.88.224: GREv1, call 830, seq 685,
ack 574, length 119: IP 62.99.71.230.2436 > 130.206.100.17.imaps: P
126:185(59) ack 624 win 64105

10:05:19.244399 IP 62.99.88.224 > 83.213.96.190: GREv1, call 55737, seq 575,
ack 685, length 60: IP 130.206.100.17.imaps > 62.99.71.230.2436: . ack 185
win 6432

10:05:19.249773 IP 62.99.88.224 > 83.213.96.190: GREv1, call 55737, seq 576,
ack 685, length 145: IP 130.206.100.17.imaps > 62.99.71.230.2436: P
624:709(85) ack 185 win 6432

10:05:19.253310 IP 83.213.96.190 > 62.99.88.224: GREv1, call 830, seq 686,
ack 576, length 118: IP 62.99.71.230.2436 > 130.206.100.17.imaps: P
185:243(58) ack 709 win 65535

10:05:19.282995 IP 83.213.96.190 > 62.99.88.224: GREv1, call 830, seq 687,
length 56: IP 62.99.71.230.2414 > 130.206.100.17.imaps: . ack 134 win 64254

10:05:19.290641 IP 62.99.88.224 > 83.213.96.190: GREv1, call 55737, seq 577,
ack 686, length 144: IP 130.206.100.17.imaps > 62.99.71.230.2436: P
709:793(84) ack 243 win 6432

10:05:19.299874 IP 83.213.96.190 > 62.99.88.224: GREv1, call 830, seq 688,
ack 577, length 122: IP 62.99.71.230.2436 > 130.206.100.17.imaps: P
243:305(62) ack 793 win 65451

10:05:19.384517 IP 62.99.88.224 > 83.213.96.190: GREv1, call 55737, seq 578,
ack 688, length 148: IP 130.206.100.17.imaps > 62.99.71.230.2436: P
793:881(88) ack 305 win 6432

10:05:19.388086 IP 83.213.96.190 > 62.99.88.224: GREv1, call 830, seq 689,
ack 578, length 118: IP 62.99.71.230.2436 > 130.206.100.17.imaps: P
305:363(58) ack 881 win 65363

Ummmss… una pista… y si tiene que ver que el tráfico vaya cifrado… (na, no
os flipeís que ya lo he comprobado ;-) )

Estoy por abrir una incidencia a Euskaltel pero… me huelo un >/dev/null

Gracias!!

Zefe

P.D. Caerá una receta, promise you! :-D

P.D… Jódete que lo que intento es montar una salida alternativa pal Proxy y
lo único que no funciona es el tráfico web. Amosandanomejodas! 

> -----Mensaje original-----

> De: eside-ghost-bounces en deusto.es [mailto:eside-ghost-bounces en deusto.es]

> En nombre de Ramón Echávarri Escribano

> Enviado el: sábado, 04 de octubre de 2008 1:30

> Para: Lista de eside-ghost

> Asunto: Re: [eside-ghost] iproute2 y la de siempre... router con 2

> salidasainternet

> 

> Hola,

> 

> >Tengo 2 estrategias posibles:

> 

> Yo, por aquello del KISS, optaría por la a.  Cuando tengas eso

> funcionando,

> por aquello de entender todo hasta el mínimo detalle, pruebas la b ;-).

> 

> >       En la misma tabla auxiliar añado una regla del tipo:

> >          ip rule add from 192.168.0.0/24 table Taux

> 

> Desde la ignoracia total, y con el ánimo de aclarar conceptos, entiendo

> que

> esto no añade una regla en la tabla de rutado, sino que añade una regla

> digamos "general" para que cierto tráfico use esa tabla concreta de

> rutado.

> 

> 

> >b)

> >Dejar la tabla main como está eliminando las 2 rutas por defecto

> >(por si las moscas)

> 

> Cuando tuve que tirar de estas historias (<abu cebolleta>haaceee yaaa

> muuuucho tieeeempooo...</abu cebolleta>) no conseguí mediante reglas que

> el

> tráfico originado en la propia máquina usara una tabla distinta de la

> main,

> así que ojo con ésto.  Igual el parámetro src que usas puede ayudar con

> eso

> (no me quedan claras todas sus implicaciones), pero por si acaso tenlo en

> cuenta.  En mi caso esas comunicaciones las generaraba un firewall

> comercial, así que igual también influia en mi problema.

> 

> Imagino que has probado más a fondo, pero por poner un ejemplo de posibles

> problemas por falta de rutas en la main... en tu script sólo asignas

> tablas

> de rutado a la 192.168.0.33 y las IPs del "balanceador".  Luego para la

> VPN

> envías ciertos paquetes a la 192.168.0.17 (voy a suponer que es un

> finalizador VPN, no otro router específico, ya que si no debería funcionar

> normalmente).  Los paquetes cifrados saldrán del finalizador VPN con

> alguna

> IP origen distinta de las que tienes con reglas, por lo que el balanceador

> deberá usar la tabla main para encaminarlos, pero al no tener ruta por

> defecto se los merienda.

> 

> Ten en cuenta también, que si el src no lo hace ¿?, parece que tendrás que

> natear lo que saques por el cable.

> 

> >El caso es que cuando meto tráfico procedente de cierta dirección (ya no

> >hablo de subred si no de algo tipo : ip rule add from 192.168.0.33 table

> >Taux)

> >na, que ahí se me pierde el tráfico. ¿hay alguna forma de mirar qué está

> >pasando? Algún tipo de log o algo en plan rápido...

> 

> Convendría que especificaras con qué tráfico concreto tienes problemas.

> Yo

> no sé de logs específicos (no digo que no los haya), pero siempre nos

> quedará el mejor amigo del administrador de redes (tcpdump, por supuesto

> ;-)).  Si lo envía mal saldrá por algún lado, y si no, lo normal es que te

> envíe algún icmp de destino inalcanzable, en cuyo caso te faltan rutas o

> reglas.

> 

> >Si planto el script... ¿igual alguno le puede echar un ojo? (lo voy a

> >plantar de toas toas :-p)

> 

> El script no lo he mirado con muchísimo detalle, y lo más llamativo para

> mí

> ya lo he comentado.  A mí no me gusta demasiado la forma de conseguir

> GWCABLE, porque si ya has borrado las rutas en una ejecución posterior, no

> creo que encuentres nada (aunque ya tendrás la ruta publicada), así que al

> menos una comprobación no estaría de más.

> 

> 

> >GWCABLE=`route |grep eth3 |grep default | cut -d " " -f 10`

> >...

> >route del default

> >route del default

> 

> Bueno, y ya ceso en esta demostración de atrevida ignorancia... por hoy,

> claro ;-p.

> 

> Saludos!!

> 

> 

> 

> 

> _______________________________________________

> eside-ghost mailing list

> eside-ghost en deusto.es

> https://listas.deusto.es/mailman/listinfo/eside-ghost

------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: https://listas.deusto.es/mailman/private/eside-ghost/attachments/20081007/8fc593d8/attachment-0001.htm 