Categorías

• General
  

  Foro destinado a las consultas de ámbito general que no puedan ser encuadradas en nuestros otros foros

  Off Topic Portada, noticias y blogs Mercadillo HardLimit

  6343
  Temas
  87836
  Mensajes

  

  Hombre, yo rollo bunker poco a poco aun me animaria, pero flotero está claro que no

  Edit: Estoy muy locooooooo

• Hardware
  

  Foro destinado a cualquier tema relacionado con el hardware y el soporte técnico

  Overclock Procesadores, placas base y memorias Tarjetas Gráficas Refrigeración, silencio y modding Redes Video, audio, foto y entretenimiento Dispositivos móviles y portátiles Configuraciones completas Aplicaciones electrónicas

  42527
  Temas
  350069
  Mensajes

  

  Voy a actualizar este tema con los resultados "temporales" obtenidos.

  En efecto gracias a la tecnica del UDP HOLE PUNCHING he podido connectar conectar un servidor y un cliente de VPN sin necesidad de abrir puertos, pero hay un PERO.

  Como bien sabreis ultimamente a los ISP les ha dado por poner CG-NAT, el cual es una ENORME PUTADA, ya que la tecnica del UDP HOLE PUNCHING no funciona bajo un CG-NAT ya que hace un PORT RANDOMIZE y entonces el Source Port del servidor VPN cambia a cada conexion que hace, por ejemplo.

  Si tengo un PC con el servidor VPN en el puerto 1194 UDP y detras de un CG-NAT, al lanzar paquetes hacia otro equipo seguramente ese 1194 sale del CG-NAT por otro puerto, el cual NO SABEMOS ya que aplica un PORT RANDOMIZE y quizas acaba saliendo por el 55123.

  He probado a usar un 3r servidor donde el "server vpn" manda unos paquetes para poder descubrir el SRC PORT tras el CG-NAT, pero claro, esa asignacion a la espera de respuesta queda solo para ese 3r servidor, a la que el cliente intenta conectar por ese agujero el CG-NAT bloquea la conexion ya que no era el destinatario original, pues en eso consiste el HOLE PUNCHING.

  Tenéis alguna idea o conocéis algun procedimiento para "saltar" esta barrera? Se que es posible pedir a la compañia que nos saque del CG-NAT, pero, eso no es una opcion valida porque al final el que correra el servidor VPN puede que este incluso detras de una conexion de movil compartida, donde no hay manera de abrir/redireccionar puertos tampoco.

  Se que lo que pido es bastante complejo, pero bueno, nunca se sabe donde puede dar uno con la solución!

  Un saludo.

  P.D: @krampak te cito por si acaso

• Software
  

  Grupo de foros dedicados al software en general y a la programación, bancos de pruebas, seguridad, etc

  Sistemas operativos Juegos

  9594
  Temas
  78377
  Mensajes

  

  Tenemos dos nuevos micros: un Xeon de @krampak y un Celeron de @Namiga. Este último en realidad lleva en la recámara 10 días, pero se me había pasado.

  El Celeron es un 3855U, lo que viene siendo un Skylake de finales de 2015. Siendo un Celeron y encima de la serie U, no se pueden esperar grandes logros y efectivamente, hay que irse a Core 2 Duo para ver micros similares en FPU. Pero este tiene algo de especial y es que aunque no tiene sets recientes como AVX1/2, su rendimiento SSE3 supera las expectativas después de ver el desempeño en el modo más básico. Y es que aquí, es comparable a un i7-860 en monohilo, una CPU algo viejuna pero de gama media/alta.

  Sobre el Xeon, es un E3-1220 v3. Se trata de un micro algo más viejo; de 2013. Es un Haswell de 4 núcleos que prácticamente calca el rendimiento de un i7-4720HQ. Teniendo en cuenta que este último es una CPU portátil con un TDP de la mitad y sólo 2 años más reciente, el Xeon no parece demasiado espectacular. También es verdad que estamos comparando un Xeon básico con el tope de gama de CPUs portátiles de Intel.