No se puede cargar el sitio web interno a través de MPLS

Tenemos un MPLS configurado entre dos subredes. Todo (es decir, tengo RDP en ambas direcciones, así como el intercambio de archivos) parece estar funcionando correctamente, excepto por dos cosas, que pueden estar relacionadas.

• Las computadoras con Windows no pueblan la "Red" con dispositivos de la otra subred.
• Desde la computadora remota, no podemos cargar nuestro sitio web interno ubicado en la red host.

WINS está habilitado y funciona , y ambas computadoras saben quién es el servidor DNS y quién es el servidor WINS.

El servidor web está en 192.168.1.20(Windows Server 2003) y la computadora (Windows 7) en la subred remota está en 192.168.2.249. Compartir archivos y RDP funcionan en ambos sentidos.

Entonces, la subred del host es 192.168.0.0/23y la subred remota es 192.168.2.0/23. Cada uno de los enrutadores Windstream tiene dos puertos: uno para MPLS y otro para Internet. En este momento, el puerto de internet en el control remoto no está conectado. El puerto de Internet en el enrutador host se ejecuta a través de nuestro enrutador firewall antes de ingresar a la red host, pero el puerto MPLS en el host se conecta directamente al switch-trunk.

Los dos enrutadores Windstream tienen un puerto MPLS:

• 192.168.1.2 = Host MPLS
• 192.168.2.2 = MPLS remoto

Los enrutadores Windstream también tienen un puerto de Internet abierto al que he conectado un enrutador de firewall para filtrar Internet, lo que hace que las puertas de enlace de Internet:

• 192.168.1.1 = Puerta de enlace de host
• 192.168.2.1 = Puerta de enlace remota

Leí aquí que necesitaba enumerar las subredes en los sitios y servicios de Active Directory, así que he creado las dos subredes como miembros de un único sitio.

Para mi prueba, los firewalls están desactivados en ambas computadoras más el servidor web.

El ISP (Windstream) confirma que MTU está configurado en 1500, y en sus pruebas, sus pings siempre se envían con un tamaño de 1500.

Entonces, ¿qué puedo tratar de resolver estos dos problemas?

Aquí hay un mapa:

[actualización] Cuando ejecuto Wireshark en el servidor web y veo la solicitud de la página web, veo muchas retransmisiones en las llamadas http. Aquí está el informe:

Parece que el tráfico http del control remoto al host es lo que está recibiendo retransmisiones. Pero no tengo equipo que pueda bloquearlo. Los firewalls están todos apagados.

Por lo tanto, puedo hacer telnet al servidor web desde una máquina en la misma subred, pero no puedo hacerlo desde una máquina en la subred remota: informa:

c:\>telnet 192.168.1.20 80
Connecting To 192.168.1.20...Could not open connection to the host, on port 80: Connect failed

Trace-Route desde el servidor web a la computadora remota:

Trace-Route desde la computadora remota al servidor web:

[Actualización] que habilita IIS en el ordenador portátil a distancia, y yo soy capaz de tirar de esa página web desde un ordenador en el lugar de acogida. Sin embargo, este siempre ha sido el caso en mis pruebas. El tráfico http, por lo tanto, es solo de una manera.

Los dos enrutadores Windstream tienen un puerto MPLS:

• 192.168.1.2 = Host MPLS
• 192.168.2.2 = MPLS remoto

Los enrutadores Windstream también tienen un puerto de Internet abierto al que he conectado un enrutador de firewall para filtrar Internet, lo que hace que las puertas de enlace de Internet:

• 192.168.1.1 = Puerta de enlace de host
• 192.168.2.1 = Puerta de enlace remota

Resumen del problema

Su problema es que tiene varios enrutadores en la misma subred:

• La puerta de enlace a Internet en 192.168.1.1
• El enrutador MPLS de Windstream en 192.168.1.2

Este es un diseño defectuoso; Entiendo completamente que "parece" que no hay nada de malo en esto, pero como están descubriendo, esta es una forma difícil de construir la red.

Después de nuestra discusión en el chat, el problema exacto es que los paquetes TCP SYN de SAINTJOSEPH se entregan correctamente; sin embargo, la inspección con estado en su firewall PaloAlto descarta la respuesta TCP SYN-ACK de SAINTSERVIUS, debido al enrutamiento asimétrico en su entorno. Esto se ilustra en los dos siguientes diagramas.

TCP SYN de SAINTJOSEPH a SAINTSERVIUS :

Su cortafuegos PaloAlto elimina el TCP SYN-ACK de SAINTSERVIUS a SAINTJOSEPH :

Esto tracertdeja muy claro que SAINTSERVIUS se establece de forma predeterminada en 192.168.1.1 (el firewall de PaloAlto):

Soluciones a largo plazo

Solo debe tener un enrutador de siguiente salto para cada subred ; sin embargo, actualmente tienes dos. Esto da como resultado las caídas que se muestran en la captura de pantalla de los cables de conexión (lo que indica que los paquetes TCP SYN-ACK nunca llegan a la red MPLS de Windstream).

Estas son dos soluciones a largo plazo que discutimos ... También incluyo el truco rápido que hicimos para validar que el problema son las caídas de paquetes con estado en el PaloAltos. Supongo que está utilizando múltiples interfaces en el PaloAlto.

• Opción A: mantenga los cortafuegos de PaloAlto en línea con sus conexiones entre oficinas (más mantenimiento)
• Opción B: mueva los cortafuegos PaloAlto frente a las conexiones a Internet (menos mantenimiento, pero también menos cómodo)
• Opción C: truco rápido de enrutamiento estático de Windows

Mejor diseño, Opción A (se requiere redireccionamiento MPLS)

Esta es otra forma de diseñar la subred para SAINTSERVIUS (conservando su esquema de numeración con subredes / 23, aunque no es obligatorio ...). Esta opción mantiene el enrutamiento entre oficinas en los firewalls de PaloAlto, que le resulta más familiar en este momento.

Esta es una solución a largo plazo. Tendría que trabajar con Windstream para volver a direccionar su infraestructura. Esto es un montón de trabajo. En mi opinión, es menos preferible mantener los firewalls en el medio de su tráfico entre oficinas.

Mejor diseño, opción B (se requiere redireccionamiento MPLS)

Esta es otra forma de diseñar la subred para SAINTSERVIUS (conservando su esquema de numeración con subredes / 23, aunque no es obligatorio ...). Esta opción descarga el enrutamiento LAN entre oficinas a los conmutadores PowerConnect y se basa en los firewalls de PaloAlto para protegerse contra las amenazas de Internet.

Esta es una solución a largo plazo. Tendría que trabajar con Windstream para volver a direccionar su infraestructura. Esto es mucho trabajo, pero ofrece la ventaja de no tener que lidiar con firewalls para la comunicación entre oficinas.

Solución subóptima, opción C (lo que usó después de nuestro chat)

Abra una cmd.exeventana y agregue esta ruta en SAINTSERVIUS como administrador:

route ADD 192.168.2.0 MASK 255.255.254.0 192.168.1.2

Palabras de clausura

Debo mencionar que usted es una de las pocas personas que siguió con suficientes detalles sobre su pregunta. Cuando comenzó, no teníamos suficientes detalles para responder la pregunta. Ahora, los problemas son muy claros; gracias por dedicar tiempo / esfuerzo a documentar bien el problema.

Nota personal: si desea copias electrónicas de los diagramas en formato SVG / Inkscape , no dude en ponerse en contacto conmigo en mi correo electrónico personal (que figura en mi perfil de usuario ).