enigma939 Buenas, una pregunta de buen rollo ¿para que necesitas exactamente el NAT Loopback?
Esta pregunta siempre me la hago cuando veo que la gente necesita NAT Loopback porque a mi no se me ocurre un solo motivo por el cual es necesario. Intentaré ofrecerte una solución alternativa a tener NAT Loopback.
Un saludo.
djbill normalmente por una de estas tres razones, aunque no sé realmente el caso del compi cual será
Algunos por una cuestión "estética", que es un poco lo que tu dices... para que a fin de cuentas si se puede usar la IP directamente.
Para otros es comodidad, para no tener diferentes perfiles (si es que son posibles) de diferntes servicios en función de si estan fuera o dentro de la red. Con Nat Loopback pudes tener sólo uno para todo. Se puede solventar siempre y cuando la aplicación que sea permita disponer de forma sencilla de multiples perfiles con los que poder conmutar, de lo contrario es un coñazo andar quitando poniendo y reconfigurando.
Y quizás el peor escenario, es una necesidad cuando trabajan en entornos de dominio donde los servicios están configurados de manera global dentro de la red, ya sean servidores de correo, bases de datos... se usa de forma muy extensa.
OK Theliel
Yo normalmente utilizo todo mediante nombres DNS y sobre todo en el tercero de los casos configuro el servidor DNS para que devuelva una IP Privada o una IP Publica en función del origen de la petición.
djbill precisamente para evitar usar eso, se usa muchas veces NAT Loopback. No deja de ser realmente una función... práctica más que necesaria la mayoría de las veces, sólo en escenarios muy concretos suele ser necesaria. Yo directamente por ejemplo sólo uso NAT Loopback por cuestiones de testeo de firewall y otros
Tass1234 no sé de donde te has sacado de la magan el MTU 1480... uyn par de cosillas
1. Las conexiones PPPoE tienen un MTU máximo de 1492. Esto no lo impone el ISP, el 99% de las veces es establecido de echo directamente. Como un Frame Ethernet tiene un payload máximo de 1500Bytes, al usar una conexión PPPoE se requiere una sobrecarga de 8 Bytes, con lo que el payload final efectivo se queda en 1492, no 1480.
2. Prácticamente la totalidad de Routers, cuando se configura la interfaz WAN a PPPoE se establece a dicho MTU, el resto de interfaces, ya sea VoIP o TV deberían de estar en 1500, y si estan en 1492 los puedes poner a 1500 sin problemas.
3. Movistar repito no establece el MTU en su red a X, el MTU lo informa el cliente a los servidores, para que estos sepan cual es la cantidad máxima de datos que pueden enviarle por paquete. Ellos no saben si tu estás detrás de una conexión PPPoE, con lo que si diesen por echo que aceptas 1500, te la liaría. Y aquí está tu segundo error...
4. Windows, Linux... la mayoría de todos los OS vienen directamente configuradas sus interfaces de red a 1500. Sí, existen protocolos de descubrimiento de MTU pero no funcionan bien y ya no son necesarios prácticamente. Da igual que configures tu cliente Windows/linux con MTU de 1492, lo único que lograrás así es que tu PC transmita datos a tus otros dispositivos a 1492 dentro de tu propia red en vez de a 1500. Por qué?? Porque da igual el MTU que uses en tu adaptador, antes de que el Router saque para fuera tus paquetes va a fijar el MTU A 1492 si el MTU es más alto que este. Evidentemente lo fija a 1492 porque usas una conexión PPPoE. Sino hiciese esto muchos equipos se tendrían que configurar manualmente para MTU de 1492... y sabes que no es así.
Esto es gracias a iptables y la archifamosa regla de fijación de MTU:
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
En realidad fija le MSS, que es el segmento maximo de los paquetes TCP. Puedes comprobarlo si quieres aquí:
http://www.speedguide.net:8080/
Te dirá el MTU que usas, y podras ver que da igual que fijes el MTU en tu PC a 1500 o a 1492, igualmente dirá que 1492. Evidentemente si lo fijas aun más bajo, prevalece por lo general el más bajo.
No te hace falta cambiar elMTU en Windows.
PPPoE MTU = 1492 (no 1480)
VoIP/TV MTU =1500
Las imágenes no salen, si quieres que salgan rapido las pones en un servidor de imágenes y pegas aquí el enlace.
Repito... las cuentas admin y supervisor fueron eliminadas en la b23, sólo queda la cuenta 1234 y la cuenta telefonica (pass telefonica) que se crea sólo si se habilita un flag concreto en el archivo de configuración, y además sólo es válida para los accesos por WAN. Bueno, también está la cuenta SAMBA, pero dado que no nos pusieron puerto USB... para poco sirve
La interfaz web y otras variables, simplemente no han limpiado todo el código relevante y referente a ello, pero como digo... no existen ya las otras cuentas
Tienes razón, no es 1480, es 1492. Dije los 1480 de memoria ya que lo calculé hace un par de años, ahora salen 1492, o se ha cambiado o lo calculé mal.
Para calcularlo lo que hago es hacer un ping de un tamaño concreto y ver si se fragmentan los paquetes o no. Este es el resultado de hoy:
http://i.imgur.com/aMRMQFU.jpg
Eso significa que con un paquete de 1464 no lo fragmenta y con uno de 1465 sí. Como TCP/IP tiene unos headers de 28 bytes, le sumo esos 28 al 1464 y me da los 1492 actuales (hace un par de años, el resultado fue de 1480).
Sobre lo del MTU en Windows, el motivo de fijarlo ahí es evitar que tenga que volver a empaquetar al salir a la WAN, no se si me explico, ya se que solo estoy modificando la medida local, pero si la local y la de salida son diferentes, es necesario un reempaquetado en el router, mientras que si coinciden, no. Igual me equivoco :)
Sobre lo de las cuentas, me refería a esta imagen:
http://i.imgur.com/aabMdCh.jpg
Pero ya he entendido lo que dices que es solo código obsoleto en el cfg.
En mi caso particular es por comodidad, ya que andar cambiando de perfirl es un rollo para todas las aplicaciones que tengo en función de si estoy dentro o fuera de la red.
