OVH Cloud OVH Cloud

Serveur 2003 inaccessible

37 réponses
Avatar
LiR
Bonjour,

J'ai un serveur Windows 2003 Server R2 SP2 sur lequel sont activés IIS6 et
les services Terminal Server en mode application.

Il possède deux cartes réseau, une LAN pour le réseau local et une WAN
connectée directement à internet par un routeur contrôlé par le FAI.

On accède à ce serveur à partir d'internet de n'importe où à l'extérieur,
pour afficher des applications Web (en ASP.NET 2.0) et/ou ouvrir des sessions
TS.

De temps en temps, mais en moyenne 2 fois par jour, le serveur ne répond
plus, pendant 1 minute ou plusieurs heures.
Cela peut se produire même en pleine nuit lorsque personne n'est connecté
sur le serveur.

J'ai constaté que lorsque le serveur ne répondait plus, la carte réseau WAN
recevait des données mais qu'aucune information n'était transmise. Par
exemple, le log d'IIS fait clairement apparaître qu'aucune requête ne lui est
parvenue de l'extérieur lors de la période de coupure.
Et, de fait, on observe que lors des coupures, la carte WAN de renvoie
aucune donnée.

J'espère que je suis au bon endroit pour poser cete question, mais cela dure
depuis plusieurs mois et je ne suis pas très calé en réseaux.

Quelqu'un saurait d'où peut provenir un tel bloquage?

En vous remerciant,

LiR

10 réponses

1 2 3 4
Avatar
LiR
En fait elle la requête ne repart pas du tout, pour la simple raison qu'elle
n'existe pas!
Car un serveur Web qui ne reçoit pas de requête ne risque pas de donner une
réponse.
Comme je l'ai dit, mon problème ce ne sont pas les données qui sortent de la
carte mais le fait que les données qui arrivent ne sont pas traitées.
Comme je ne suis pas un expert j'aimerais savoir ce qui peut empêcher le
traitement de données reçues par une carte réseau. Un composant logiciel
(firewall, protection ou autre)? Le fait que les données reçues sont
endommagées et donc incomprises par la machine? Je ne sais pas comment
identifier cela.

"Y.E." a écrit :

oui ta requete arrive par la carte wan mais rien te dit qu'elle ne repart
pas par l'autre passerelle.


"LiR" a écrit dans le message de news:

> Y.E., je te remercie beaucoup de persévérer et de m'aider.
>
> Je vais refaire un petit résumé de la situation.
>
> En fait, l'objectif est de pouvoir accéder aux 2 serveurs distincts depuis
> l'extérieur à partir de 2 adresses différentes (une adresse propre à
> chaque
> serveur).
> Comme je le disais, tout le problème vient de là. Ce n'est pas un
> "besoin",
> c'est le but.
>
> Je veux donc que mes 2 serveurs hébergent chacun un site internet sur une
> adresse qui lui est propre et accessible depuis l'extérieur.
> Mon routeur Bewan ne peut pas faire de la redirection d'adressage IP,
> juste
> du mappage de port, ce qui ne nous suffit donc pas (et il est hors de
> question de différencier les serveurs Web visés par insertion dun port
> dans
> l'adresse, d'autant que certains partenaires ont leurs ports autre que 80
> bloqués).
>
> A propos des erreurs dans le journal, c'était un peu ma question de
> départ
> : comment puis-je diagnostiquer ce qui a déclenché la rupture d'accès au
> serveur TS.
> Mais dans les divers journaux, logs, moniteurs (y compris le moniteur
> réseau), je n'ai rien trouvé qui puisse avoir un rapport quelconque avec
> le
> coupures.
>
> Et, comme je l'ai indiqué, le symptôme est étonnant du fait que la carte
> WAN
> reçoit les données sans aucun problème. Par exemple lorsque, depuis
> l'extérieur, j'envoie une requête HTTP sur le serveur TS en utilisant son
> adresse publique, je vois bien les données qui arrivent sur la carte WAN.
> Ce qui se vérifie autrement bien par le fait que le serveur est pingable
> depuis l'extérieur sur son adresse publique même lorsqu'il y a rupture.
> Mais le log d'IIS me le montre bien : lorsque la rupture intervient, ces
> données, qui sont réellement reçues par la carte WAN, ne parviennent plus
> à
> IIS !
>
> Lorsque les ruptures se produisent, aucune des données reçues n'est
> fournie
> à quelque application que ce soit : IIS, TS, etc. J'ai même fait une appli
> client/serveur pour tester : idem.
>
> Pour moi ce n'est donc pas un problème inhérent au fait que le serveur ne
> saurait pas par où passer...
> D'ailleurs j'ai fait un test en forçant les services TS à n'utiliser que
> la
> carte WAN, cela n'a rien changé. Pourtant, cette carte ne peut utiliser
> qu'un
> chemin : routeur Nérim puis Internet.
>
> D'où ma question : Quelle "chose" sur mon serveur a ce pouvoir de bloquer
> l'utilisation des données entrantes . Comment l'identifier?
>
>
> "Y.E." a écrit :
>
>> change de prestataire....
>> si tu peux mettre ton serveur sur 2 reseau distinct
>> mais
>> comment veux tu que ton serveur sache par ou passer puisque tu lui dit
>> que
>> tout ce qui est hors reseau passe soit par la droite (LAN) soit par la
>> gauche (WAN).
>> Tu as d'ailleurs certainement des erreurs dans l'observateur d'évènement.
>>
>> mais a quoi peuvent bien etre utilsé tes deux cartes réseau ?????
>>
>> vu que ta conf est batarde (excuse moi)
>>
>> la solution la plus propre est
>>
>> Routeur Nerim connecté a ton routeur bewan lui même connecté a ton LAN
>> les deux serveurs sur le LAN
>> PAT de ton Routeur bewan vers tes adresses LAN serveurs
>> Tu n'attaqueras de l'exterieur qu'une et seule meme adresse publique
>>
>> Tes besoins imposent t'il obligatoirement deux adtresses publiques ?
>>
>>
>> "LiR" a écrit dans le message de
>> news:
>> > Bonjour,
>> >
>> > Je crois aussi que tu as raison.
>> >
>> > En fait, j'avais demandé à l'origine la mise en place d'un reverse
>> > proxy
>> > pour assurer la redirection par adresse IP sur l'un ou l'autre des
>> > serveurs,
>> > mais notre prestataire nous a proposé cette configuration qui repose
>> > sur
>> > un
>> > pool d'adresses IP... Qui aurait été, j'imagine, plus adaptée si on
>> > avait
>> > réellement 2 réseaux distincts indépendants derrière chaque adresse IP
>> > (.34
>> > et .35)
>> >
>> > On ne peut pas agir sur le routeur nerim, c'est une sorte de "boîte
>> > noire"
>> > dont Nérim gère la configuration à distance.
>> >
>> > La conclusion serait donc :
>> > Soit mettre un seul routeur en lieu et place du Nérim (routeur capable
>> > de
>> > faire une redirection par adressage IP, mais configurable comme notre
>> > Bewan
>> > pour le reste de la configuration - redirection des ports, filtrage,
>> > etc.)
>> > Soit mettre en place un Reverse Proxy, genre ISA Server, sur le serveur
>> > principal
>> > Ce qui donnerait, dans les 2 cas, une configuration où le srveur "TS"
>> > n'aurait finalement plus qu'une seule carte réseau.
>> >
>> > Par contre, l'histoire de la passerelle unique m'étonne car les 2
>> > prestataires qui sont intervenus (notre prestataire habituel et un
>> > prestataire spécialisé qui a été missionné pour résoudre le problème)
>> > n'ont
>> > pas eu l'air de remettre cela en cause.
>> > C'est le second prestataire qui a fini par activer le routage sur le
>> > serveur
>> > "TS" pour essayer de contrôler les routes un peu mieux.
>> >
>> > La conclusion finale semble être qu'il ne fait pas mettre un serveur
>> > sur 2
>> > réseaux en même temps non?
>> >
>> > Je n'ai pas compris, c'est quoi du "SUP"
>> >
>> > "Y.E." a écrit :
>> >
>> >> oui, mais pourquoi utiliser 2 routeurs faire du SUP sur celui de nerim
>> >> pour
>> >> translater finalement par le tiens ????
>> >> il aurait été peu-être plus simple de faire du NAT et du PAT
>> >> directement
>> >> avec celui de NERIM non ?
>> >>
>> >> et puis en plus tu continue a faire du routage avec tes deux carte sur
>> >> ton
>> >> serveur ....
>> >>
>> >> pourquoi faire simple je te le demande.
>> >>
>> >> je trouve que c'est "un rien" n'importe quoi, mais n'ai je peut-être
>> >> pas
>> >> toutes les données...
>> >>
>> >> dans tous les cas 1 Machine ne peut avoir qu'une passerelle par
>> >> defaut
>> >> et
>> >> non deux !!!!
>> >>
>> >>
>> >>
>> >>
>> >> "LiR" a écrit dans le message de
>> >> news:
>> >> > Bonjour,
>> >> >
>> >> > Merci beaucoup pour toute votre aide à tous les deux.
>> >> >
>> >> > Voulez-vous dire qu'il ne faut pas spécifier de passerelle par
>> >> > défaut
>> >> > pour
>> >> > la carte LAN?
>> >> > Pour la carte WAN, la passerelle par défaut est effectivement celle
>> >> > qui
>> >> > a
>> >> > été indiquée par Nérim (celle qui finit par .33)
>> >> >
>> >> > Pour répondre également à YE., je vais récapituler la configuration
>> >> > du
>> >> > réseau :
>> >> >
>> >> > Nous avons un accès Internet dans notre agence qui est assuré par
>> >> > Nerim,
>> >> > qui
>> >> > nous a fourni un pool d'adresse.
>> >> > En amont de cette accès, à l'agence, nous avons un routeur fourni
>> >> > par
>> >> > Nerim.
>> >> >
>> >> > Nous avons également un réseau local dans cette agence, qui est géré
>> >> > par
>> >> > un
>> >> > routeur Bewan.
>> >> > ce réseau comporte des machines et 2 serveurs :
>> >> > - Un serveur "principal", qui est contrôleur de domaine, serveur de
>> >> > données,
>> >> > serveur DNS, serveur TS en mode Administration, et serveur Web
>> >> > (IIS).
>> >> > - Un serveur "TS" qui est serveur TS en mode Application et serveur
>> >> > Web
>> >> > (IIS)
>> >> >
>> >> > Ce que nous voulons obtenir, c'est pouvoir accéder au serveur
>> >> > "principal"
>> >> > (adresse locale 192.168.1.251) à partir de l'extérieur via l'adresse
>> >> > du
>> >> > pool
>> >> > finissant par .34.
>> >> > Cela est assuré par le passage par le routeur nerim, qui envoie
>> >> > l'asdresse
>> >> > .34 vers le routeur Bewan, ce dernier redirigeant, par exemple, le
>> >> > port
>> >> > 80
>> >> > vers le serveur 251
>> >> >
>> >> > Nous voulons également accéder au serveur "TS" (adresse locale
>> >> > 192.168.1.252) à partir de l'extérieur à partir de l'adresse du pool
>> >> > finissant par .35.
>> >> > cela est assuré par le passage par le routeur de nérim, qui envoie
>> >> > l'adresse
>> >> > .35 vers la carte réseau WAN du serveur TS. On peut ainsi accéder à
>> >> > ce
>> >> > serveur, principalement utilisé pour faire du TS et du Web.
>> >> > Ce serveur "TS" a parallèlement une carte réseau LAN qui lui permet
>> >> > de
>> >> > communiquer avec le réseau local, notamment avec le serveur
>> >> > "principal".
>> >> > Il est à noter que le routeur Bewan renvoie les demandes TS vers ce
>> >> > serveur
>> >> > 252, donc on peut accéder en TS sur ce serveur par les 2 adresses
>> >> > extérieures
>> >> > .34 (passe par Nerim puis Bewan et la carte LAN) et .35 (passe par
>> >> > Nérim
>> >> > puis
>> >> > la carte WAN)
>> >> >
>> >> > J'espère que j'ai été assez clair sans être trop long...
>> >> >
>> >> >
>> >> > "GG" a écrit :
>> >> >
>> >> >> Bonjour;
>> >> >>
>> >> >> > D'après toi, je devais donc mettre la même passerelle et le même
>> >> >> > serveur DNS pour chaque carte.
>> >> >>
>> >> >> Pas de passerelle sur le réseau interne et sur l'interface chez
>> >> >> Nérim
>> >> >> indiqué l'adresse du routeur que Nerim vous a indiqué ou l'adresse
>> >> >> de votre routeur.
>> >> >>
>> >> >> Par ailleurs sur les 2 interfaces indiquez le DNS 127.0.0.1 c'est a
>> >> >> dire puisque le serveur est serveur DNS configurer les DNS de
>> >> >> Nerim comme redirecteur de votre serveur DNS et aussi le
>> >> >> deuxieme serveur DNS de votre reseau 192.168.1.251
>> >> >>
>> >> >> --
>> >> >> Cordialement.
>> >> >> GG.
>> >> >> http://forums.sbsfr.org/
>> >> >> http://sbsfr.mvps.org/
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>>
>>





Avatar
....

reste sur tes positions si tu le souhaite. moi je reste sur les miennes
tant que la partie IP ne sera pas clean et stable je ne vois pas comment on
pourra diagnostiquer quoique ce soit.

bon courage


"LiR" a écrit dans le message de
news:
En fait elle la requête ne repart pas du tout, pour la simple raison
qu'elle
n'existe pas!
Car un serveur Web qui ne reçoit pas de requête ne risque pas de donner
une
réponse.
Comme je l'ai dit, mon problème ce ne sont pas les données qui sortent de
la
carte mais le fait que les données qui arrivent ne sont pas traitées.
Comme je ne suis pas un expert j'aimerais savoir ce qui peut empêcher le
traitement de données reçues par une carte réseau. Un composant logiciel
(firewall, protection ou autre)? Le fait que les données reçues sont
endommagées et donc incomprises par la machine? Je ne sais pas comment
identifier cela.

"Y.E." a écrit :

oui ta requete arrive par la carte wan mais rien te dit qu'elle ne repart
pas par l'autre passerelle.


"LiR" a écrit dans le message de news:

> Y.E., je te remercie beaucoup de persévérer et de m'aider.
>
> Je vais refaire un petit résumé de la situation.
>
> En fait, l'objectif est de pouvoir accéder aux 2 serveurs distincts
> depuis
> l'extérieur à partir de 2 adresses différentes (une adresse propre à
> chaque
> serveur).
> Comme je le disais, tout le problème vient de là. Ce n'est pas un
> "besoin",
> c'est le but.
>
> Je veux donc que mes 2 serveurs hébergent chacun un site internet sur
> une
> adresse qui lui est propre et accessible depuis l'extérieur.
> Mon routeur Bewan ne peut pas faire de la redirection d'adressage IP,
> juste
> du mappage de port, ce qui ne nous suffit donc pas (et il est hors de
> question de différencier les serveurs Web visés par insertion dun port
> dans
> l'adresse, d'autant que certains partenaires ont leurs ports autre que
> 80
> bloqués).
>
> A propos des erreurs dans le journal, c'était un peu ma question de
> départ
> : comment puis-je diagnostiquer ce qui a déclenché la rupture d'accès
> au
> serveur TS.
> Mais dans les divers journaux, logs, moniteurs (y compris le moniteur
> réseau), je n'ai rien trouvé qui puisse avoir un rapport quelconque
> avec
> le
> coupures.
>
> Et, comme je l'ai indiqué, le symptôme est étonnant du fait que la
> carte
> WAN
> reçoit les données sans aucun problème. Par exemple lorsque, depuis
> l'extérieur, j'envoie une requête HTTP sur le serveur TS en utilisant
> son
> adresse publique, je vois bien les données qui arrivent sur la carte
> WAN.
> Ce qui se vérifie autrement bien par le fait que le serveur est
> pingable
> depuis l'extérieur sur son adresse publique même lorsqu'il y a rupture.
> Mais le log d'IIS me le montre bien : lorsque la rupture intervient,
> ces
> données, qui sont réellement reçues par la carte WAN, ne parviennent
> plus
> à
> IIS !
>
> Lorsque les ruptures se produisent, aucune des données reçues n'est
> fournie
> à quelque application que ce soit : IIS, TS, etc. J'ai même fait une
> appli
> client/serveur pour tester : idem.
>
> Pour moi ce n'est donc pas un problème inhérent au fait que le serveur
> ne
> saurait pas par où passer...
> D'ailleurs j'ai fait un test en forçant les services TS à n'utiliser
> que
> la
> carte WAN, cela n'a rien changé. Pourtant, cette carte ne peut utiliser
> qu'un
> chemin : routeur Nérim puis Internet.
>
> D'où ma question : Quelle "chose" sur mon serveur a ce pouvoir de
> bloquer
> l'utilisation des données entrantes . Comment l'identifier?
>
>
> "Y.E." a écrit :
>
>> change de prestataire....
>> si tu peux mettre ton serveur sur 2 reseau distinct
>> mais
>> comment veux tu que ton serveur sache par ou passer puisque tu lui dit
>> que
>> tout ce qui est hors reseau passe soit par la droite (LAN) soit par
>> la
>> gauche (WAN).
>> Tu as d'ailleurs certainement des erreurs dans l'observateur
>> d'évènement.
>>
>> mais a quoi peuvent bien etre utilsé tes deux cartes réseau ?????
>>
>> vu que ta conf est batarde (excuse moi)
>>
>> la solution la plus propre est
>>
>> Routeur Nerim connecté a ton routeur bewan lui même connecté a ton LAN
>> les deux serveurs sur le LAN
>> PAT de ton Routeur bewan vers tes adresses LAN serveurs
>> Tu n'attaqueras de l'exterieur qu'une et seule meme adresse publique
>>
>> Tes besoins imposent t'il obligatoirement deux adtresses publiques ?
>>
>>
>> "LiR" a écrit dans le message de
>> news:
>> > Bonjour,
>> >
>> > Je crois aussi que tu as raison.
>> >
>> > En fait, j'avais demandé à l'origine la mise en place d'un reverse
>> > proxy
>> > pour assurer la redirection par adresse IP sur l'un ou l'autre des
>> > serveurs,
>> > mais notre prestataire nous a proposé cette configuration qui repose
>> > sur
>> > un
>> > pool d'adresses IP... Qui aurait été, j'imagine, plus adaptée si on
>> > avait
>> > réellement 2 réseaux distincts indépendants derrière chaque adresse
>> > IP
>> > (.34
>> > et .35)
>> >
>> > On ne peut pas agir sur le routeur nerim, c'est une sorte de "boîte
>> > noire"
>> > dont Nérim gère la configuration à distance.
>> >
>> > La conclusion serait donc :
>> > Soit mettre un seul routeur en lieu et place du Nérim (routeur
>> > capable
>> > de
>> > faire une redirection par adressage IP, mais configurable comme
>> > notre
>> > Bewan
>> > pour le reste de la configuration - redirection des ports, filtrage,
>> > etc.)
>> > Soit mettre en place un Reverse Proxy, genre ISA Server, sur le
>> > serveur
>> > principal
>> > Ce qui donnerait, dans les 2 cas, une configuration où le srveur
>> > "TS"
>> > n'aurait finalement plus qu'une seule carte réseau.
>> >
>> > Par contre, l'histoire de la passerelle unique m'étonne car les 2
>> > prestataires qui sont intervenus (notre prestataire habituel et un
>> > prestataire spécialisé qui a été missionné pour résoudre le
>> > problème)
>> > n'ont
>> > pas eu l'air de remettre cela en cause.
>> > C'est le second prestataire qui a fini par activer le routage sur le
>> > serveur
>> > "TS" pour essayer de contrôler les routes un peu mieux.
>> >
>> > La conclusion finale semble être qu'il ne fait pas mettre un serveur
>> > sur 2
>> > réseaux en même temps non?
>> >
>> > Je n'ai pas compris, c'est quoi du "SUP"
>> >
>> > "Y.E." a écrit :
>> >
>> >> oui, mais pourquoi utiliser 2 routeurs faire du SUP sur celui de
>> >> nerim
>> >> pour
>> >> translater finalement par le tiens ????
>> >> il aurait été peu-être plus simple de faire du NAT et du PAT
>> >> directement
>> >> avec celui de NERIM non ?
>> >>
>> >> et puis en plus tu continue a faire du routage avec tes deux carte
>> >> sur
>> >> ton
>> >> serveur ....
>> >>
>> >> pourquoi faire simple je te le demande.
>> >>
>> >> je trouve que c'est "un rien" n'importe quoi, mais n'ai je
>> >> peut-être
>> >> pas
>> >> toutes les données...
>> >>
>> >> dans tous les cas 1 Machine ne peut avoir qu'une passerelle par
>> >> defaut
>> >> et
>> >> non deux !!!!
>> >>
>> >>
>> >>
>> >>
>> >> "LiR" a écrit dans le message de
>> >> news:
>> >> > Bonjour,
>> >> >
>> >> > Merci beaucoup pour toute votre aide à tous les deux.
>> >> >
>> >> > Voulez-vous dire qu'il ne faut pas spécifier de passerelle par
>> >> > défaut
>> >> > pour
>> >> > la carte LAN?
>> >> > Pour la carte WAN, la passerelle par défaut est effectivement
>> >> > celle
>> >> > qui
>> >> > a
>> >> > été indiquée par Nérim (celle qui finit par .33)
>> >> >
>> >> > Pour répondre également à YE., je vais récapituler la
>> >> > configuration
>> >> > du
>> >> > réseau :
>> >> >
>> >> > Nous avons un accès Internet dans notre agence qui est assuré par
>> >> > Nerim,
>> >> > qui
>> >> > nous a fourni un pool d'adresse.
>> >> > En amont de cette accès, à l'agence, nous avons un routeur fourni
>> >> > par
>> >> > Nerim.
>> >> >
>> >> > Nous avons également un réseau local dans cette agence, qui est
>> >> > géré
>> >> > par
>> >> > un
>> >> > routeur Bewan.
>> >> > ce réseau comporte des machines et 2 serveurs :
>> >> > - Un serveur "principal", qui est contrôleur de domaine, serveur
>> >> > de
>> >> > données,
>> >> > serveur DNS, serveur TS en mode Administration, et serveur Web
>> >> > (IIS).
>> >> > - Un serveur "TS" qui est serveur TS en mode Application et
>> >> > serveur
>> >> > Web
>> >> > (IIS)
>> >> >
>> >> > Ce que nous voulons obtenir, c'est pouvoir accéder au serveur
>> >> > "principal"
>> >> > (adresse locale 192.168.1.251) à partir de l'extérieur via
>> >> > l'adresse
>> >> > du
>> >> > pool
>> >> > finissant par .34.
>> >> > Cela est assuré par le passage par le routeur nerim, qui envoie
>> >> > l'asdresse
>> >> > .34 vers le routeur Bewan, ce dernier redirigeant, par exemple,
>> >> > le
>> >> > port
>> >> > 80
>> >> > vers le serveur 251
>> >> >
>> >> > Nous voulons également accéder au serveur "TS" (adresse locale
>> >> > 192.168.1.252) à partir de l'extérieur à partir de l'adresse du
>> >> > pool
>> >> > finissant par .35.
>> >> > cela est assuré par le passage par le routeur de nérim, qui
>> >> > envoie
>> >> > l'adresse
>> >> > .35 vers la carte réseau WAN du serveur TS. On peut ainsi accéder
>> >> > à
>> >> > ce
>> >> > serveur, principalement utilisé pour faire du TS et du Web.
>> >> > Ce serveur "TS" a parallèlement une carte réseau LAN qui lui
>> >> > permet
>> >> > de
>> >> > communiquer avec le réseau local, notamment avec le serveur
>> >> > "principal".
>> >> > Il est à noter que le routeur Bewan renvoie les demandes TS vers
>> >> > ce
>> >> > serveur
>> >> > 252, donc on peut accéder en TS sur ce serveur par les 2 adresses
>> >> > extérieures
>> >> > .34 (passe par Nerim puis Bewan et la carte LAN) et .35 (passe
>> >> > par
>> >> > Nérim
>> >> > puis
>> >> > la carte WAN)
>> >> >
>> >> > J'espère que j'ai été assez clair sans être trop long...
>> >> >
>> >> >
>> >> > "GG" a écrit :
>> >> >
>> >> >> Bonjour;
>> >> >>
>> >> >> > D'après toi, je devais donc mettre la même passerelle et le
>> >> >> > même
>> >> >> > serveur DNS pour chaque carte.
>> >> >>
>> >> >> Pas de passerelle sur le réseau interne et sur l'interface chez
>> >> >> Nérim
>> >> >> indiqué l'adresse du routeur que Nerim vous a indiqué ou
>> >> >> l'adresse
>> >> >> de votre routeur.
>> >> >>
>> >> >> Par ailleurs sur les 2 interfaces indiquez le DNS 127.0.0.1
>> >> >> c'est a
>> >> >> dire puisque le serveur est serveur DNS configurer les DNS de
>> >> >> Nerim comme redirecteur de votre serveur DNS et aussi le
>> >> >> deuxieme serveur DNS de votre reseau 192.168.1.251
>> >> >>
>> >> >> --
>> >> >> Cordialement.
>> >> >> GG.
>> >> >> http://forums.sbsfr.org/
>> >> >> http://sbsfr.mvps.org/
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>>
>>







Avatar
GG
Bonjour,

oui, mais pourquoi utiliser 2 routeurs faire du SUP sur celui de
nerim pour translater finalement par le tiens ????



Pour une meilleure sécurité 2 sécurité vallent mieux qu'une.

il aurait été peu-être plus simple de faire du NAT et du PAT
directement avec celui de NERIM non ?



Comme cela si attaquant perce le routeur Nerim le reseau de
l'entreprise est a l'air libre. :(

--
Cordialement.
GG.
http://forums.sbsfr.org/
http://sbsfr.mvps.org/
Avatar
GG
Bonjour,

D'où ma question : Quelle "chose" sur mon serveur a ce pouvoir de
bloquer l'utilisation des données entrantes . Comment l'identifier?



Le pare-feu de RRAS.
Si vous l'avez activé il se peut que tout soit fermé.
Il faut aller dans la console RRAS et ouvrir les propriétés de
votre connexion WAN dans les propriétés vous allez trouver
deux boutons Filtre en Entrée et Sortie verifier qu'une relation
ne bloque pas tout.

--
Cordialement.
GG.
http://forums.sbsfr.org/
http://sbsfr.mvps.org/
Avatar
LiR
Bonjour,

Merci de persévérer et de m'aider!

Le pare-feu de base est effectivement activé sur WAN
Cependant, aucun filtre n'a été défini en entrée ni en sortie.
Concernant les services Web et Bureau à distance, ils ont bien été activés
sur les ports standards.
En fait, lorsque je me suis penché sur le problème, j'ai imaginé
effectivement que c'était un blocage de sécurité. Ayant trouvé dans les logs
des quantités industrielles d'attaque de brute force sur les comptes ADMIN,
ADMINISTRATOR, etc., j'ai mis en place le pare-feu sur WAN. Et ça a plutôt eu
tendance à stabiliser le système!

Mais j'imagine que si le pare-feu devait bloquer quelque chose, il le ferait
en permanance, et non de temps en temps comme le bloquage qu'on constate?
Car en dehors de ces coupures qui reviennent environ 2 fois par jour, le
système tourne excessivement bien.

Car en temps réel, je vois que si je fais une requête HTTP à partir de mon
ordinateur distant, les données arrivent sur la WAN. Mais ne sont pas
transmises (en l'occurence) à IIS. Cela pourrait être parce que ces données
endommagées ne peuvent pas être interprétées comme une requête HTTP...
Je me dis que les données qui arrivent sur la carte WAN sont peut-être
endommagées, ce serait pourquoi elles ne sont pas correctement interprétées
par la machine. Je vais essayer de trouver un outil pour vérifier cela...

Le plus intriguant reste ceci : lors des coupures, les clients qui étaient
déjà connectés (en TS ou en HTTP), continuent de pouvoir accéder au serveur.
Je crois que ça peut avoir un rapport avec le "mappage de session" que j'ai
vu dans RRAS, mais je ne sais pas exactement ce que c'est.



"GG" a écrit :

Bonjour,

> D'où ma question : Quelle "chose" sur mon serveur a ce pouvoir de
> bloquer l'utilisation des données entrantes . Comment l'identifier?

Le pare-feu de RRAS.
Si vous l'avez activé il se peut que tout soit fermé.
Il faut aller dans la console RRAS et ouvrir les propriétés de
votre connexion WAN dans les propriétés vous allez trouver
deux boutons Filtre en Entrée et Sortie verifier qu'une relation
ne bloque pas tout.

--
Cordialement.
GG.
http://forums.sbsfr.org/
http://sbsfr.mvps.org/





Avatar
securité????

ou securité il y a, puisque le serveur a une carte connecté directement avec
une ip publique !!!!

il y a des normes, des standard, et des bases!!!

maintenant ne pas les respecter c'est un choix de chacun. mais de la à dire
que c'est comme ca et que ca ne marche pas à l'arrivée, faut pas se
plaindre.

son RAS ne sert a rien, sinon a mélanger les tables de routage avec ses deux
passerelles.

merci a toi de l'aider quand même, moi je renonce, car diagnostiquer un
problème sans eliminer les causes une a une ben je ne sais pas faire.

je dois être une bille.....



"GG" a écrit dans le message de news:

Bonjour,

oui, mais pourquoi utiliser 2 routeurs faire du SUP sur celui de
nerim pour translater finalement par le tiens ????



Pour une meilleure sécurité 2 sécurité vallent mieux qu'une.

il aurait été peu-être plus simple de faire du NAT et du PAT
directement avec celui de NERIM non ?



Comme cela si attaquant perce le routeur Nerim le reseau de
l'entreprise est a l'air libre. :(

--
Cordialement.
GG.
http://forums.sbsfr.org/
http://sbsfr.mvps.org/



Avatar
LiR
Bonjour,

Je ne suis pas resté sur mes positions! J'ai un peu regardé à quoi servait
une passerelle (à la base je suis développeur, pas administrateur réseau).
J'en ai déduit qu'ici la passerelle sert à relier l'ordinateur (le serveur
"TS") à Internet.
Donc, la carte WAN doit effectivement avoir cette passerelle, puisqu'on veut
qu'elle serve pour l'accès extérieur.
Et du coup, j'imagine que la LAN reste totalement sur le réseau local.
Est-ce bien cela?
En tous cas, si c'est bien ça et que la WAN ne décroche pas, ce serait bien
car c'est précisément ce qu'on voulait obenir.

J'ai supprimé la passerelle par défaut de la LAN.
Le fait est que du coup, effectivement, on ne peut plus accéder au serveur
par l'extérieur autrement que par sa carte WAN (donc j'imagine qu'on ne passe
plus, en aucun cas, par le routeur Bewan en se connectant de l'extérieur).
Je vais voir si ça améliore les choses...

"Y.E." a écrit :

.....

reste sur tes positions si tu le souhaite. moi je reste sur les miennes
tant que la partie IP ne sera pas clean et stable je ne vois pas comment on
pourra diagnostiquer quoique ce soit.

bon courage


"LiR" a écrit dans le message de
news:
> En fait elle la requête ne repart pas du tout, pour la simple raison
> qu'elle
> n'existe pas!
> Car un serveur Web qui ne reçoit pas de requête ne risque pas de donner
> une
> réponse.
> Comme je l'ai dit, mon problème ce ne sont pas les données qui sortent de
> la
> carte mais le fait que les données qui arrivent ne sont pas traitées.
> Comme je ne suis pas un expert j'aimerais savoir ce qui peut empêcher le
> traitement de données reçues par une carte réseau. Un composant logiciel
> (firewall, protection ou autre)? Le fait que les données reçues sont
> endommagées et donc incomprises par la machine? Je ne sais pas comment
> identifier cela.
>
> "Y.E." a écrit :
>
>> oui ta requete arrive par la carte wan mais rien te dit qu'elle ne repart
>> pas par l'autre passerelle.
>>
>>
>> "LiR" a écrit dans le message de news:
>>
>> > Y.E., je te remercie beaucoup de persévérer et de m'aider.
>> >
>> > Je vais refaire un petit résumé de la situation.
>> >
>> > En fait, l'objectif est de pouvoir accéder aux 2 serveurs distincts
>> > depuis
>> > l'extérieur à partir de 2 adresses différentes (une adresse propre à
>> > chaque
>> > serveur).
>> > Comme je le disais, tout le problème vient de là. Ce n'est pas un
>> > "besoin",
>> > c'est le but.
>> >
>> > Je veux donc que mes 2 serveurs hébergent chacun un site internet sur
>> > une
>> > adresse qui lui est propre et accessible depuis l'extérieur.
>> > Mon routeur Bewan ne peut pas faire de la redirection d'adressage IP,
>> > juste
>> > du mappage de port, ce qui ne nous suffit donc pas (et il est hors de
>> > question de différencier les serveurs Web visés par insertion dun port
>> > dans
>> > l'adresse, d'autant que certains partenaires ont leurs ports autre que
>> > 80
>> > bloqués).
>> >
>> > A propos des erreurs dans le journal, c'était un peu ma question de
>> > départ
>> > : comment puis-je diagnostiquer ce qui a déclenché la rupture d'accès
>> > au
>> > serveur TS.
>> > Mais dans les divers journaux, logs, moniteurs (y compris le moniteur
>> > réseau), je n'ai rien trouvé qui puisse avoir un rapport quelconque
>> > avec
>> > le
>> > coupures.
>> >
>> > Et, comme je l'ai indiqué, le symptôme est étonnant du fait que la
>> > carte
>> > WAN
>> > reçoit les données sans aucun problème. Par exemple lorsque, depuis
>> > l'extérieur, j'envoie une requête HTTP sur le serveur TS en utilisant
>> > son
>> > adresse publique, je vois bien les données qui arrivent sur la carte
>> > WAN.
>> > Ce qui se vérifie autrement bien par le fait que le serveur est
>> > pingable
>> > depuis l'extérieur sur son adresse publique même lorsqu'il y a rupture.
>> > Mais le log d'IIS me le montre bien : lorsque la rupture intervient,
>> > ces
>> > données, qui sont réellement reçues par la carte WAN, ne parviennent
>> > plus
>> > à
>> > IIS !
>> >
>> > Lorsque les ruptures se produisent, aucune des données reçues n'est
>> > fournie
>> > à quelque application que ce soit : IIS, TS, etc. J'ai même fait une
>> > appli
>> > client/serveur pour tester : idem.
>> >
>> > Pour moi ce n'est donc pas un problème inhérent au fait que le serveur
>> > ne
>> > saurait pas par où passer...
>> > D'ailleurs j'ai fait un test en forçant les services TS à n'utiliser
>> > que
>> > la
>> > carte WAN, cela n'a rien changé. Pourtant, cette carte ne peut utiliser
>> > qu'un
>> > chemin : routeur Nérim puis Internet.
>> >
>> > D'où ma question : Quelle "chose" sur mon serveur a ce pouvoir de
>> > bloquer
>> > l'utilisation des données entrantes . Comment l'identifier?
>> >
>> >
>> > "Y.E." a écrit :
>> >
>> >> change de prestataire....
>> >> si tu peux mettre ton serveur sur 2 reseau distinct
>> >> mais
>> >> comment veux tu que ton serveur sache par ou passer puisque tu lui dit
>> >> que
>> >> tout ce qui est hors reseau passe soit par la droite (LAN) soit par
>> >> la
>> >> gauche (WAN).
>> >> Tu as d'ailleurs certainement des erreurs dans l'observateur
>> >> d'évènement.
>> >>
>> >> mais a quoi peuvent bien etre utilsé tes deux cartes réseau ?????
>> >>
>> >> vu que ta conf est batarde (excuse moi)
>> >>
>> >> la solution la plus propre est
>> >>
>> >> Routeur Nerim connecté a ton routeur bewan lui même connecté a ton LAN
>> >> les deux serveurs sur le LAN
>> >> PAT de ton Routeur bewan vers tes adresses LAN serveurs
>> >> Tu n'attaqueras de l'exterieur qu'une et seule meme adresse publique
>> >>
>> >> Tes besoins imposent t'il obligatoirement deux adtresses publiques ?
>> >>
>> >>
>> >> "LiR" a écrit dans le message de
>> >> news:
>> >> > Bonjour,
>> >> >
>> >> > Je crois aussi que tu as raison.
>> >> >
>> >> > En fait, j'avais demandé à l'origine la mise en place d'un reverse
>> >> > proxy
>> >> > pour assurer la redirection par adresse IP sur l'un ou l'autre des
>> >> > serveurs,
>> >> > mais notre prestataire nous a proposé cette configuration qui repose
>> >> > sur
>> >> > un
>> >> > pool d'adresses IP... Qui aurait été, j'imagine, plus adaptée si on
>> >> > avait
>> >> > réellement 2 réseaux distincts indépendants derrière chaque adresse
>> >> > IP
>> >> > (.34
>> >> > et .35)
>> >> >
>> >> > On ne peut pas agir sur le routeur nerim, c'est une sorte de "boîte
>> >> > noire"
>> >> > dont Nérim gère la configuration à distance.
>> >> >
>> >> > La conclusion serait donc :
>> >> > Soit mettre un seul routeur en lieu et place du Nérim (routeur
>> >> > capable
>> >> > de
>> >> > faire une redirection par adressage IP, mais configurable comme
>> >> > notre
>> >> > Bewan
>> >> > pour le reste de la configuration - redirection des ports, filtrage,
>> >> > etc.)
>> >> > Soit mettre en place un Reverse Proxy, genre ISA Server, sur le
>> >> > serveur
>> >> > principal
>> >> > Ce qui donnerait, dans les 2 cas, une configuration où le srveur
>> >> > "TS"
>> >> > n'aurait finalement plus qu'une seule carte réseau.
>> >> >
>> >> > Par contre, l'histoire de la passerelle unique m'étonne car les 2
>> >> > prestataires qui sont intervenus (notre prestataire habituel et un
>> >> > prestataire spécialisé qui a été missionné pour résoudre le
>> >> > problème)
>> >> > n'ont
>> >> > pas eu l'air de remettre cela en cause.
>> >> > C'est le second prestataire qui a fini par activer le routage sur le
>> >> > serveur
>> >> > "TS" pour essayer de contrôler les routes un peu mieux.
>> >> >
>> >> > La conclusion finale semble être qu'il ne fait pas mettre un serveur
>> >> > sur 2
>> >> > réseaux en même temps non?
>> >> >
>> >> > Je n'ai pas compris, c'est quoi du "SUP"
>> >> >
>> >> > "Y.E." a écrit :
>> >> >
>> >> >> oui, mais pourquoi utiliser 2 routeurs faire du SUP sur celui de
>> >> >> nerim
>> >> >> pour
>> >> >> translater finalement par le tiens ????
>> >> >> il aurait été peu-être plus simple de faire du NAT et du PAT
>> >> >> directement
>> >> >> avec celui de NERIM non ?
>> >> >>
>> >> >> et puis en plus tu continue a faire du routage avec tes deux carte
>> >> >> sur
>> >> >> ton
>> >> >> serveur ....
>> >> >>
>> >> >> pourquoi faire simple je te le demande.
>> >> >>
>> >> >> je trouve que c'est "un rien" n'importe quoi, mais n'ai je
>> >> >> peut-être
>> >> >> pas
>> >> >> toutes les données...
>> >> >>
>> >> >> dans tous les cas 1 Machine ne peut avoir qu'une passerelle par
>> >> >> defaut
>> >> >> et
>> >> >> non deux !!!!
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> "LiR" a écrit dans le message de
>> >> >> news:
>> >> >> > Bonjour,
>> >> >> >
>> >> >> > Merci beaucoup pour toute votre aide à tous les deux.
>> >> >> >
>> >> >> > Voulez-vous dire qu'il ne faut pas spécifier de passerelle par
>> >> >> > défaut
>> >> >> > pour
>> >> >> > la carte LAN?
>> >> >> > Pour la carte WAN, la passerelle par défaut est effectivement
>> >> >> > celle
>> >> >> > qui
>> >> >> > a
>> >> >> > été indiquée par Nérim (celle qui finit par .33)
>> >> >> >
>> >> >> > Pour répondre également à YE., je vais récapituler la
>> >> >> > configuration
>> >> >> > du
>> >> >> > réseau :
>> >> >> >
>> >> >> > Nous avons un accès Internet dans notre agence qui est assuré par
>> >> >> > Nerim,
>> >> >> > qui
>> >> >> > nous a fourni un pool d'adresse.
>> >> >> > En amont de cette accès, à l'agence, nous avons un routeur fourni
>> >> >> > par
>> >> >> > Nerim.
>> >> >> >
>> >> >> > Nous avons également un réseau local dans cette agence, qui est
>> >> >> > géré
>> >> >> > par
>> >> >> > un
>> >> >> > routeur Bewan.
>> >> >> > ce réseau comporte des machines et 2 serveurs :
>> >> >> > - Un serveur "principal", qui est contrôleur de domaine, serveur
>> >> >> > de
>> >> >> > données,
>> >> >> > serveur DNS, serveur TS en mode Administration, et serveur Web
>> >> >> > (IIS).
>> >> >> > - Un serveur "TS" qui est serveur TS en mode Application et
>> >> >> > serveur
>> >> >> > Web
>> >> >> > (IIS)
>> >> >> >
>> >> >> > Ce que nous voulons obtenir, c'est pouvoir accéder au serveur
>> >> >> > "principal"
>> >> >> > (adresse locale 192.168.1.251) à partir de l'extérieur via
>> >> >> > l'adresse
>> >> >> > du
>> >> >> > pool
>> >> >> > finissant par .34.
>> >> >> > Cela est assuré par le passage par le routeur nerim, qui envoie
>> >> >> > l'asdresse
>> >> >> > .34 vers le routeur Bewan, ce dernier redirigeant, par exemple,
>> >> >> > le
>> >> >> > port
>> >> >> > 80
>> >> >> > vers le serveur 251
>> >> >> >
>> >> >> > Nous voulons également accéder au serveur "TS" (adresse locale
>> >> >> > 192.168.1.252) à partir de l'extérieur à partir de l'adresse du
>> >> >> > pool
>> >> >> > finissant par .35.
>> >> >> > cela est assuré par le passage par le routeur de nérim, qui
>> >> >> > envoie
>> >> >> > l'adresse
>> >> >> > .35 vers la carte réseau WAN du serveur TS. On peut ainsi accéder
>> >> >> > à
>> >> >> > ce
>> >> >> > serveur, principalement utilisé pour faire du TS et du Web.
>> >> >> > Ce serveur "TS" a parallèlement une carte réseau LAN qui lui
>> >> >> > permet
>> >> >> > de
>> >> >> > communiquer avec le réseau local, notamment avec le serveur
>> >> >> > "principal".
>> >> >> > Il est à noter que le routeur Bewan renvoie les demandes TS vers
>> >> >> > ce


Avatar
GG
Bonjour,

Car en temps réel, je vois que si je fais une requête HTTP à partir
de mon ordinateur distant, les données arrivent sur la WAN. Mais ne
sont pas transmises (en l'occurence) à IIS. Cela pourrait être parce
que ces données endommagées ne peuvent pas être interprétées comme
une requête HTTP...



Sur RRAS avez-vous publier votre port 80 ?

Je me dis que les données qui arrivent sur la carte WAN sont peut-être
endommagées, ce serait pourquoi elles ne sont pas correctement
interprétées par la machine. Je vais essayer de trouver un outil pour
vérifier cela...



Il faudrait installé netmon et jeter un oeil dans les traces pour mieux
comprendre ce qu'il se passe.

Le plus intriguant reste ceci : lors des coupures, les clients qui
étaient déjà connectés (en TS ou en HTTP), continuent de pouvoir
accéder au serveur.



Normal cela est prévu pour et si il n'y a pas changement d'IP il y a
reprise sur une deconnexion, dans le protocole RDP c'est parfaitement
prévu.

--
Cordialement.
GG.
http://forums.sbsfr.org/
un livre sur SBS http://livresbs.sbsfr.org/
Avatar
LiR
Bonjour et merci,

Concernant le port 80, q'uentendez-vous par "publier" ?
Comme je l'ai dit, j'ai activé les ports HTTP et Bureau à distance dans le
pare-feu de base sur la carte WAN.

Comme je l'ai dit également, netmon est mis en place. Mais je n'y ai trouvé
aucune information utile sur l'explication du problème. Il m'informe que des
données transitent sur la carte WAN, ce que je sais déjà.


"GG" a écrit dans le message de
news:
Bonjour,

Car en temps réel, je vois que si je fais une requête HTTP à partir
de mon ordinateur distant, les données arrivent sur la WAN. Mais ne
sont pas transmises (en l'occurence) à IIS. Cela pourrait être parce
que ces données endommagées ne peuvent pas être interprétées comme
une requête HTTP...



Sur RRAS avez-vous publier votre port 80 ?

Je me dis que les données qui arrivent sur la carte WAN sont peut-être
endommagées, ce serait pourquoi elles ne sont pas correctement
interprétées par la machine. Je vais essayer de trouver un outil pour
vérifier cela...



Il faudrait installé netmon et jeter un oeil dans les traces pour mieux
comprendre ce qu'il se passe.

Le plus intriguant reste ceci : lors des coupures, les clients qui
étaient déjà connectés (en TS ou en HTTP), continuent de pouvoir
accéder au serveur.



Normal cela est prévu pour et si il n'y a pas changement d'IP il y a
reprise sur une deconnexion, dans le protocole RDP c'est parfaitement
prévu.

--
Cordialement.
GG.
http://forums.sbsfr.org/
un livre sur SBS http://livresbs.sbsfr.org/



Avatar
GG
Bonjour,

Concernant le port 80, q'uentendez-vous par "publier" ?



Configurer le pare-feu pour que depuis l'exterieur on puisse accéder
au port 80, et ensuite avec netmon dans les trames si il y a deconnexion
vous devez les voir passer soit celles du serveur soit celle du client
distant.

--
Cordialement.
GG.
http://forums.sbsfr.org/
un livre sur SBS http://livresbs.sbsfr.org/
1 2 3 4