Impossible de charger le site Web interne sur MPLS

Nous avons un MPLS installé entre deux sous-réseaux. Tout (c'est-à-dire que j'ai RDP dans les deux sens ainsi que le partage de fichiers) semble fonctionner correctement, sauf deux choses, qui peuvent être liées.

• Les ordinateurs Windows ne remplissent pas le «réseau» avec des périphériques de l'autre sous-réseau.
• Depuis l'ordinateur distant, nous ne pouvons pas charger notre site Web interne situé sur le réseau hôte.

WINS est activé et fonctionne , et les deux ordinateurs savent qui est le serveur DNS et qui est le serveur WINS.

Le serveur Web est à 192.168.1.20(Windows Server 2003) et l'ordinateur (Windows 7) dans le sous-réseau distant est à 192.168.2.249. Le partage de fichiers et RDP fonctionnent dans les deux sens.

Ainsi, le sous-réseau hôte est 192.168.0.0/23et le sous-réseau distant est 192.168.2.0/23. Chacun des routeurs Windstream a deux ports - un pour MPLS et un pour Internet. À l'heure actuelle, le port Internet de la télécommande n'est pas connecté. Le port Internet du routeur hôte passe par notre routeur pare-feu avant d'entrer dans le réseau hôte, mais le port MPLS de l'hôte se branche directement sur le tronc du commutateur.

Les deux routeurs Windstream ont chacun un port MPLS:

• 192.168.1.2 = MPLS hôte
• 192.168.2.2 = MPLS distant

Les routeurs Windstream ont également chacun un port Internet ouvert auquel j'ai attaché un routeur pare-feu pour filtrer Internet, ce qui rend les passerelles Internet:

• 192.168.1.1 = Passerelle hôte
• 192.168.2.1 = Passerelle distante

J'ai lu ici que je devais répertorier les sous-réseaux dans les sites et services Active Directory, j'ai donc créé les deux sous-réseaux en tant que membres d'un même site.

Pour mes tests, les pare-feu sont désactivés sur les deux ordinateurs ainsi que sur le serveur Web.

L'ISP (Windstream) confirme que MTU est réglé sur 1500, et dans leurs tests, leurs pings sont toujours envoyés avec une taille de 1500.

Alors, que puis-je essayer de résoudre ces deux problèmes?

Voici une carte:

[mise à jour] Lorsque j'exécute Wireshark sur le serveur Web et que je regarde la demande de page Web, je vois beaucoup de retransmissions sur les appels http. Voici le rapport:

Il semble que le trafic http de la télécommande vers l'hôte soit ce qui obtient les retransmissions. Mais je n'ai pas d'équipement qui puisse le bloquer. Les pare-feu sont tous éteints.

Donc, je peux telnet au serveur web depuis une machine sur le même sous-réseau, mais je ne peux pas telnet depuis une machine sur le sous-réseau distant - il rapporte:

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 du serveur Web à l'ordinateur distant:

Trace-Route de l'ordinateur distant au serveur Web:

[mise à jour] J'ai activé IIS sur l'ordinateur portable distant et je peux extraire cette page Web d'un ordinateur à l'emplacement de l'hôte. Cela a toujours été le cas, cependant, dans mes tests. Le trafic http n'est donc qu'une façon.

Les deux routeurs Windstream ont chacun un port MPLS:

• 192.168.1.2 = MPLS hôte
• 192.168.2.2 = MPLS distant

Les routeurs Windstream ont également chacun un port Internet ouvert auquel j'ai attaché un routeur pare-feu pour filtrer Internet, ce qui rend les passerelles Internet:

• 192.168.1.1 = Passerelle hôte
• 192.168.2.1 = Passerelle distante

Résumé du problème

Votre problème est que vous avez plusieurs routeurs sur le même sous-réseau:

• La passerelle Internet au 192.168.1.1
• Le routeur Windstream MPLS à 192.168.1.2

Ceci est une conception défectueuse; Je comprends parfaitement qu'il "semble" qu'il n'y a rien de mal à cela, mais comme vous le découvrez, c'est un moyen difficile de construire le réseau.

Suite à notre discussion par chat, le problème exact est que les paquets TCP SYN de SAINTJOSEPH sont livrés correctement; cependant, une inspection dynamique de votre pare-feu PaloAlto supprime la réponse TCP SYN-ACK de SAINTSERVIUS, en raison du routage asymétrique dans votre environnement. Ceci est illustré dans les deux schémas suivants.

TCP SYN de SAINTJOSEPH à SAINTSERVIUS :

Votre pare-feu PaloAlto supprime le TCP SYN-ACK de SAINTSERVIUS à SAINTJOSEPH :

Cela tracertmontre très clairement que SAINTSERVIUS utilise par défaut 192.168.1.1 (le pare-feu PaloAlto):

Solutions à long terme

Vous ne devriez avoir qu'un seul routeur suivant pour chaque sous-réseau ; cependant, vous en avez actuellement deux. Cela se traduit par les pertes affichées dans votre capture d'écran Wireshark (ce qui indique que les paquets TCP SYN-ACK n'atteignent jamais le réseau MPLS de Windstream).

Ce sont deux solutions à long terme dont nous avons discuté ... J'inclus également le hack rapide que nous avons fait pour valider que le problème est la perte de paquets avec état sur le PaloAltos. Je suppose que vous utilisez plusieurs interfaces sur le PaloAlto.

• Option A: Gardez les pare-feu PaloAlto en ligne avec vos connexions inter-bureaux (plus de maintenance)
• Option B: déplacer les pare-feu PaloAlto devant les connexions Internet (moins de maintenance, mais aussi moins confortable)
• Option C: piratage de routage statique rapide de Windows

Meilleure conception, option A (réadressage MPLS requis)

C'est une autre façon de disposer le sous-réseau pour SAINTSERVIUS (en conservant votre schéma de numérotation avec les sous-réseaux / 23, bien que ce ne soit pas obligatoire ...). Cette option conserve le routage inter-bureaux sur les pare-feu PaloAlto, qui vous semble plus familier en ce moment.

Il s'agit d'une solution à long terme. Vous devrez travailler avec Windstream pour réadapter votre infrastructure. C'est beaucoup de travail. À mon avis, garder les pare-feu au milieu de votre trafic inter-bureaux est moins préférable.

Meilleure conception, option B (réadressage MPLS requis)

C'est une autre façon de disposer le sous-réseau pour SAINTSERVIUS (en conservant votre schéma de numérotation avec les sous-réseaux / 23, bien que ce ne soit pas obligatoire ...). Cette option décharge le routage LAN inter-bureaux vers vos commutateurs PowerConnect et s'appuie sur les pare-feu PaloAlto pour se protéger contre les menaces Internet.

Il s'agit d'une solution à long terme. Vous devrez travailler avec Windstream pour réadapter votre infrastructure. C'est beaucoup de travail, mais cela offre l'avantage de ne pas avoir à gérer les pare-feu pour votre communication inter-bureaux.

Solution de contournement sous-optimale, Option C (ce que vous avez utilisé après notre discussion)

Ouvrez une cmd.exefenêtre et ajoutez cet itinéraire sur SAINTSERVIUS en tant qu'administrateur:

route ADD 192.168.2.0 MASK 255.255.254.0 192.168.1.2

Remarques de clôture

Je dois mentionner que vous êtes l'une des rares personnes à avoir donné suffisamment de détails sur votre question. Lorsque vous avez commencé, nous n'avions pas suffisamment de détails pour répondre à la question. Maintenant, les problèmes sont très clairs; merci d'avoir consacré du temps et des efforts à bien documenter le problème.

Remarque personnelle: Si vous souhaitez une copie électronique des diagrammes au format SVG / Inkscape , n'hésitez pas à me contacter via mon e-mail personnel (répertorié dans mon profil utilisateur ).