o Como meterle un poco el dedo en el culo a Speedy
Como todos ya habran notado, Telefonica ( Speedy ) esta filtrando / limitando el trafico de programas p2p ( Azureus, uTorrent, etc.). Si bien para algunos esto no representa ningun problema, no deja de ser una burda y estupida manera de limitarnos (Como si los clientes p2p fueran ilegales).
Esta especificado en el contrato,el cual varia segun el tipo de servicio que se tenga, (LEANLO BIEEENNN) que pueden limitar este tipo de trafico. Igualmente nosotros podemos hacer que nuestro trafico sea lo menos “detectable” posible.
Continuen leyendo si estan interesados en saber como hacerlo
Como?
Encriptando nuestros paquetes para que al pasar por el ISP, este no sepa diferenciar una hamburguesa de un salamin.
Igualmente, tengan en cuenta que la encriptacion radica en la “compatibilidad” entre clientes. Por lo que si yo tengo un cliente que no soporta encriptacion (los mas conocidos ya la soportan) y quiero comunicarme con uno que SOLO acepta conexiones encriptadas, no voy a poder hacerlo.
Por otra parte si empezamos a realizar conexiones sin encriptar y el ISP lo detecta, entonces puede llegar a limitarnos directamente por el puerto que utilizemos para realizar cualquier tipo de conexion torrent.
Tengo entendido (corrigame alguien si no es asi) que las especificaciones de la encriptacion indican que no es necesario que el cliente que vaya a conectarse con nosotros haga todos estos pasos, simplemente necesita utilizar un cliente que soporte encriptacion para que al requerirla, se utilize.
Como comenzar a encriptar nuestro trafico torrent
Si bien esto es MUY FACIL de hacer, ya que casi todos los clientes/programas lo tienen implementado como una opcion, no es muy sabido.
Voy explicar como hacerlo con 2 clientes: Azureus que creo que a esta altura es el mas utilizado y el uTorrent, el que usa Fede que me pregunto como solucionar este problema.
NOTA: Si alguien quiere me envia la explicacion de como hacerlo para otro cliente y yo lo agrego, pero no me pregunten como hacerlo para el cliente torrent que usan uds.. Usen uno de estos dos o averiguen por ahi como hacerlo.
Paso a explicarles:
uTorrent
Options &45;> Preferences &45;> Network
Abajo van a ver que dice “Protocol Encryption” ahi eligen “Enabled”
La diferencia entre Enabled y Forced basicamente es que Forced, si al encriptar la conexion saliente falla no va a intentar hacerlo sin encriptar la transmision.
Empiezen probando con “Enabled” y marcando la casilla que dice “Allow legacy incoming connections” que es para permitir que se comuniquen con nosotros clientes sin que ellos encripten. Si tienen que seleccionar Forced, pueden probar deshabilitando tambien este tipo de conexiones.
Azureus
Tools &45;> Options &45;> Connection &45;> Transport Encryption
Primero deben marcar “Require Encrypted Transport”
Esto va a consumir un poco mas de CPU por el intercambio de keys.
Luego en “Minimum encryption level” tienen dos opciones Plain y RC4:
Plain, es una encriptacion de las cabezeras y el resto lo transmite sin encriptar.
RC4, es muchisimo mas complicado de detectar.
Utilizen RC4, aunque va a consumir mas CPU que Plain.
Despues tienen dos checkbox (Marcamos ambas)
Allow non&45;encrypted outgoing connections if encrypted connection attempt fails
Esto es como un fallback, es decir, intenta conectarse a un cliente que no soporta encriptacion, si no puede, intenta hacerlo sin encriptacion.
Allow non&45;encrypted incoming connections
Al desmarcarla, evitamos que se conecten clientes con nosotros a no ser que utilizen encriptacion.
Para terminar
Les recomiendo tambien utilizar otro puerto, pueden probar con uno al azar o utilizando alguno de un servicio conocido como el 80 o el 21)
Y prueben las distintas combinaciones para ver cual les da mejores resultados, les dejo un cuadro muy lindo que encontre en el wiki de azureus como para que vean las ventajas y desventajas de cada combinacion.
| Level | Enabled | Method | allow outgoing fallback | allow incoming fallback | advantages | disadvantages |
|---|---|---|---|---|---|---|
| 0 | No + using a non&45;standard port | none | Yes | Yes | Doesn’t use cryptography unless required by a peer; no additional CPU consumption | Doesn’t prevent traffic shaping, unless the provider simply throttles standard P2P ports |
| 1 | Yes | Plain | Yes | Yes | Least CPU intensive and most compatible setting to avoid traffic shaping | Easy to detect since the payload isn’t encrypted |
| 2 | Yes | RC4 | Yes | Yes | Still maintains maximum compatibility but avoids traffic shaping, at least for outgoing connections | The incoming port used for BT connections may be detected |
| 3 | Yes | RC4 | Yes | No | Prevents that any classic BT connection to the incoming port is successful and thus makes it harder to identify ports that are used for BT traffic | Limited backwards compatibility |
| 4 | Yes | RC4 | No | No | Prevents any classic BT connection and thus makes it harder to identify the entire host as a BT user | No backwards compatibility at all |
| 5 | Yes + setting tools &45;> options &45;> tracker &45;> client &45;> override tracker announce port to 0 | RC4 | No | No | Tells the tracker not to hand out your local IP and thus prevents any classic BT connection attempts | Severely limits the number of peers that can establish incoming connections to you |
