El Vidente

Viendo el más allá de las noticias.

Problemas entre MTU y sistemas VPN.

Desde hace algún tiempo me consultan acerca de problemas que se presentan en redes VPN IPSec con el MTU (La unidad máxima de transferencia o Maximum Transfer Unit) y trataré de explicar por qué se producen estos problemas.

Ejemplos de MTU para distintos protocolos usados en Internet:

Ethernet: 1518 bytes
PPPoE: 1492 bytes
ATM (AAL5): 8190 bytes
FDDI: 4470 bytes
PPP: 576 bytes

Para el caso de IP (Protocolo de Internet), el máximo valor de la MTU es 65.536 bytes pero este es en realidad un valor teórico. El tamaño del datagrama IP por defecto es 576 bytes y esto tiene que ver con el hecho de que un datagrama IP atravesará varios tipos de red IP antes de llegar hasta su destino y se debería estar seguro de que puede atravesar toda red en su camino. En la actualidad casi todas las redes están basadas en productos Ethernet y sus derivados por lo que se ha fijado de hecho el tamaños del MTU en 1500 bytes.

El protocolo ICMP es necesario para que PMTUD (Path MTU Discovery) funcione. Esto consiste en una serie de mensajes ICMP que establecen el tamaño maximo del MTU de destino y por lo tanto el tamaño máximo del datagrama que podemos enviar al destino.

Para descubrir el MTU hasta algún destino, se utiliza una técnica conocida como PMTU-D “Path MTU – Discovery”, la cual depende de un paquete icmp de tipo “destination-unreachable” con código “Fragmentation needed but DF set” (tipo 3, código 4).

Cada vez más administradores de red con poco conocimiento real del protocolo IP y para evitar ataques de negación de servicio (DoS) se dedican a bloquear el pineo en general (ping) o protocolo ICMP (de capa cuatro según el modelo OSI) y esto trae problemas en la interoperabilidad de las redes al no funcionar PMTUD y no poder determinar el maximo MTU del destino.

El problema con las VPN IPSEC

Los datagramas IPSEC no deben ser fragmentados para preservar la integridad de los datos cifrados. Cuando un datagrama llega a un Gateway IPSec se le suman a los 1500 bytes que trae los datos de encabezamiento IPSec por lo que el datagrama sobrepasa los 1500 bytes. Como el administrador de la red cerró los pines es decir bloqueó el protocolo ICMP en su totalidad, los equipos carecen de una herramienta que les permite averiguar el MTU de destino y son bloqueados al no poder disminuirse el tamaño del datagrama según sea necesario.

La solución en Linux y Openswan:

Los sistemas linux vienen por defecto con el PMTUD desactivado y debe ser activado agregando al archivo /etc/sysctl.conf lo siguiente:

net.ipv4.ip_no_pmtu_disc=0

No bloquer los mesajes de PING o ICMP de icmp de tipo “destination-unreachable” con código “Fragmentation needed but DF set” (tipo 3, código 4).

Spam de origen peruano.

Viendo los logs de mis servidores de correo he encontrado muchos dominios que son usados únicamente para enviarnos SPAM.  Son dominios casi descartables o los reutilizan despues de algún tiempo.  Todos son ".info" seguramente porque registradores como Godaddy los venden a menos de un dolar el primer año.

Me parece que el spam es de origen peruano, no lo sé en realidad porque a mi no me llega, le llega a mis clientes pero he visto algunos de los Asuntos de los e-mails y parece dirigido objetivamente a Perú.  Este SPAM es bastante bien elaborado ya que burla perfectamente al SpamAssasin logrando puntajes de 1, 2 ó incluso -2.5 ó por el estilo.  Estos Spammers tampoco están registrados en Spamhaus, Spamcop u otras listas negras importantes.

Aquí un ejemplo logs del servidor de correo donde un mensaje de estos obtiene apenas 2.3 como Score de SPAM en SpamAssasin; un puntaje así no suele considerarse SPAM.

2009-08-13 13:17:38 1Mberj-0001vh-PT H=(server1.nestorcanales.info) [67.228.89.172] Warning: "SpamAssassin as cclamor detected message as NOT spam (2.3)"
2009-08-13 13:17:38 1Mberj-0001vh-PT <= minas34@elvavillavicencio.info H=(server1.nestorcanales.info) [67.228.89.172] P=esmtps

2009-08-13 13:17:38 1Mberj-0001vh-PT H=(server1.nestorcanales.info) [67.228.89.172] Warning: "SpamAssassin as cclamor detected message as NOT spam (2.3)"
2009-08-13 13:17:38 1Mberj-0001vh-PT <= minas34@elvavillavicencio.info H=(server1.nestorcanales.info) [67.228.89.172] P=esmtps X=TLSv1:AES256-SHA:256 S=139189 id=002101ca1ca4$a4cd18ac$e0a2cfa9@xotcwle

Les dejo algunos de los dominios detectados:

elvavillavicencio.info
nestorcanales.info
adrianacuba.info
waltercampos.info
danielariveros.info
maximovillanueva.info
antoniacortez.info
joanrodriguez.info
fiorellacastro.info

Y como yo uso Exim 4 como servidor de correo, he puesto temporalmente este filtro hasta que encuentre una mejor forma de detener este SPAM.

if $header_from: contains "@adrianacuba.info" or

$header_from: contains "@waltercampos.info" or

$header_from: contains "@nestrocorrales.info" or

$header_from: contains "@elvavillavicencio.info"

$header_from: contains "@danielariveros.info" or

$header_from: contains "@joanrodriguez.info" or

$header_from: contains "@fiorellacastro.info"

then

seen finish

endif

RCP, el NIC.PE y los RFC

Los RFC son las reglas que determinan como se implementa un servicio en Internet.  Se supone que las organizaciones de máximo nivel en Internet manejan y aplican los RFC correctamente.  RCP ( Red Científica Peruana ) gobierna o maneja todos los dominios “.pe” pero no aplica los RFC. RCP tiene un whois por web pero la regla (RFC) dice que debe ser por puerto tcp 43.

Hay un sitio web que he descubierto hoy (al parecer aun me queda algo de sitios por descubir ) que se denomina RFC Ignorant www.rfc-ignorant.org

Ellos listan a sitios que no aplican  los RFC.

Bueno, me encontre todo el “.pe” listado en RFC-Ignorant por no tener un whois.

Los RFC referentes al whois está aquí: http://www.rfc-ignorant.org/policy-whois.php

Y el “.pe” está aquí: http://www.rfc-ignorant.org/tools/detail.php?domain=pe&submitted=1047954047&table=whois

Cuándo podremos tener un whois decente en Perú para que todos los softwares y sistemas que requieren un whois server (tcp 43) puedan funcionar correctamente.

Con paciencia se puede obtener una rebaja en Godaddy.

Hace unos días se venció el dominio “robertobolivar.info” que es el dominio original de este Blog. Fuí a renovarlo en Godaddy y me quizo cobrar US$ 19.00 por la renovación anual lo que me pareció excesivo; cuando lo registré originalmente Godaddy tenía una oferta de US$ 1.99 o algo así por los dominios .info. Luego al renovarlo anualmente me cobró alrededor de US$ 10.00 y me pareció razonable pero la renovación para el tercer año fue de US$ 19.00

Pues decidí no renovarlo y cambairlo al dominio “sorcier.pe” uno que tenía comprado sin uso y así fué, y ya mi blog se mudó de dominio.

Lo más curioso es que hoy entré a ver si me animaba a renovar el domnio “robertobolivar.info” que se habia quedado en el carrito de compras y me encontré con un precio de US$ 8.29 y ni rastros de los US$ 19.00 de antes.

Aqui viene lo bueno, en una ocasión anterior intenté comprar un Certificado Digital de Godaddy y llegué hasta el carrito de compras pero me pareció elevado el precio y ahí lo dejé. Luego de unas semanas me bajaron el precio en un 40% aproxiamadamente y me animé y lo compré; por lo visto lo mismo ha pasado esta vez con mi dominio.

Me parece que si haces esperar a Godaddy dejando cosas en el carrito de compras te hará una rebaja para que compres de todas maneras. Será cierto esto o solamente fue una coincidencia?

El negocio del Hosting y Sunat.

Más de uno nos hemos preguntado como se maneja el pago de impuestos a SUNAT por los servicios de hosting que compramos en el extranjero mediante tarjetas de crédito y como ese es uno de mis negocios me puse a averiguar.

El proveedor extranjero se denomina “no domiciliado”. Cuando uno compra un producto o servicio para ser vendido o revendido en el Perú entonces se considera que el producto genera “renta de fuente peruana” y por lo tanto está afecto al impuesto a la renta del 30%. Tambíen está afecto al IGV pero el IGV puede ser usado como crédito fiscal el mismo mes en el que se paga, por lo tanto, queda en cero.

La ley dice que el comprador “domiciliado” (nosotros) debe retener al vendedor “no domiciliado” el 30% del impuesto a la renta y el 19% del IGV. Es decir, si vamos por un servicio que cuesta US$ 100.00 debemos retener US$ 30.00 de Renta y US$ 19.00 de IGV con lo que el proveedor no domiciliado solo debería recibir US$ 51.00.

En la práctica no sucede la retención, yo compro un servicio de alojamiento web por US$ 100.00 mensuales y eso exactamente es lo que me carga a la tárjeta de crédito el proveedor no domiciliado y entonces se genera un problema: NO RETUVE y no puedo usar esa operacion como gasto.

Con esta situación yo fuí a ORIENTACIÓN AL CONTRIBUYENTE de SUNAT y resulta que no sabían y no podían decirme como pago o como regularizo ese impuesto. El ente recaudador no sabe como se hace.

Por qué deseo pagar el IMPUESTO? Más de uno se lo estará preguntando y la respuesta es sencilla y clara: Al final de año tenemos la declaración anual de Impuesto a la Renta y si no declaro esos pagos al extanjero, no puedo usar esos montos como gasto y descontarlos de la renta y entonces debo pagar una renta elevada ya que esos US$ 100.00 al no estar declarados como gasto pasan como utilidad.

La ley me da una salida: Si no retienes no lo declaras como gasto. En ese caso no hay delito pero hay renta elevada porque pagamos impuestos sobre un monto que realmente es un gasto.

Esto es lo que encontré al tratar de pagar ese impuesto. Se agradece cualquier colaboración que esclarezca el tema.

Enlaces relacionados:
http://www.sunat.gob.pe/legislacion/oficios/2005/oficios/i0112005.htm