Topic: adresses locales non masquées ???

[jibe]

Salut,

J'ai un petit problème sur un serveur 6.0.1 sur lequel mes seules modifications par rapport à l'origine ont été d'ajouter le rapatriement de plusieurs boites mail selon la méthode décrite par Spox.

Avec ce serveur, il m'est impossible d'accéder à aucun site extérieur par https, alors que le http fonctionne bien, le https en local aussi, et le https avec lynx depuis le serveur aussi !

Tcpdump me montre que mon adresse locale n'est pas masquée :
16:39:04.722579 192.168.1.16.1418 > 217.70.177.41.https: S 28969441:28969441(0) win 8192 <mss 1460,nop,nop,sackOK> (DF)

Quelqu'un a une piste ou une suggestion ?

[jibe]

Bonjour,

Je viens de faire un essai sur un autre serveur avec les mêmes contribs d'installées. Tout fonctionne à merveille !

J'ai certainement fait quelque chose sur ce serveur qui m'a foutu en l'air le https... Mais quoi ? Je ne vois vraiment pas ?

J'ai comparé les règles du firewall (obtenues par iptables -L) et elles sont identiques sur les deux serveurs...

Quelqu'un a-t-il une idée ou un conseil sur la façon dont je pourrais localiser le problème ?

[onsy]

Salut,

Peut-être que tu pourrais commencer par comparer les configurations entre le serveur qui fonctionne et le tien ? (par le server-manager : vérifier la configuration).

[jibe]

Bonjour,

J'ai pris le serveur, reconfiguré pour le faire fonctionner sur mon réseau, l'ai déclaré en passerelle, et tout fonctionne !

Je le ramène sur site, change
[list=1]

• L'adresse IP (192.168.1.2 pour le faire marcher en second serveur sur mon réseau, 192.168.1.1 sur site)
• l'interface de connexion web (modem RTC sur ttyS0 chez moi, carte RNIS sur ttyI0 sur site)
• Le n° de téléphone du Fai (0 pour prendre la ligne sur site, absent chez moi)
[/list:o]

Chez moi, le tcpdump montre bien le masquage des trames sortantes, sur site pas de masquage...

=> Je ne vois pas d'autre explication qu'un bug dans le masquage des adresses en cas de connexion RNIS.

Bug qui ne doit pas être bien grave, le problème est que je connais assez bien FreeEOS (basé sur SME 5.5) et ses ipchains, mais pas du tout SME et ses iptables...

Quelqu'un peut m'aider ? Merci !

[jibe]

Salut,

J'ai trouvé ce topic dans lequel un problème similaire au mien est exposé. Mais j'ai essayé d'appliquer la solution (forcer l'utilisation du proxy sur les postes locaux), et je n'ai pas de meilleur résultat...

Je me suis aperçu que j'ai aussi des problèmes avec ftp...

J'ai vu aussi que les cartes RNIS internes ne sont pas supportées, mais la mienne (Elsa microlink ISDN PCI) est reconnue par le système et fonctionne très bien en pop, smtp et http...

Une idée, une piste, un conseil ?

et merci d'avance !

[onsy]

Bonjour,
Bien, bien, bien, posons le problème :

  1- Ton accès par RNIS n'est pas en cause : sinon il n'y aurait pas d'aacès du tout (pas http, ni accès en direct depuis serveur)
  2- Tes accès en http passent, dc il ne s'agit pas d'un pbl de routage depuis  ton poste client

Maintenant, qlqs questions sups :
qd tu fais ton tcpdump qui t'amène à dire que ton adresse n'est pas NATée, tu le fais sur quelle interface ?
Tu as quoi ds le cas d'un http ?

Tout ceci, c'est pour cerner un peu mieux le problème.

[jibe]

Bonjour,

Merci de te pencher sur mon problème ! Je n'ai pas le serveur sous la main, mais comme je me suis déjà posé les mêmes questions, je devrais pouvoir répondre assez précisément quand même. Au besoin, je serai sur site cet après-midi.

qd tu fais ton tcpdump qui t'amène à dire que ton adresse n'est pas NATée, tu le fais sur quelle interface ?

Je fais un tcpdump -i ippp0. Je crois avoir aussi tenté un tcpdump -i ttyI0 et ne me souviens pas avoir noté quoi que ce soit qui donne une indication supplémentaire intéressante. Un tcpdump -i ppp0 sur une bécane qui a un accès V90 (avec https qui marche !) donne bien des adresses masquées (NATées si tu préfères).

Tu as quoi ds le cas d'un http ?

De tête, j'ai la même chose avec mon IP publique en lieu et place de l'IP locale.

1- Ton accès par RNIS n'est pas en cause : sinon il n'y aurait pas d'aacès du tout (pas http, ni accès en direct depuis serveur)
2- Tes accès en http passent, dc il ne s'agit pas d'un pbl de routage depuis ton poste client

C'est bien ce que je me suis dit aussi. Et donc, ceci éliminé, il reste quoi ? Je ne vois qu'une chose : l'IP masquerade qui ne fonctionne pas sur l'interface utilisée, non ? Donc une règle manquante dans le firewall du genre (je ne connais pas IPtables -> description du principe) :

Code: [Select]

De 192.168.1.0/24 vers 0.0.0.0/0 avec <[https] ou [ippp0] ou [port... j'ai oublié lequel]> MASQ
Ai-je raison ou pas ? Ou y a-t-il une autre possibilité de dysfonctionnement que j'oublie ou ignore ?

Si c'est bien ça, dans quel template devrait être générée la règle manquante ? (ou comment le trouver...)

Merci.

[jibe]

Re...

En relisant un peu le tout, je m'aperçois que dans ce post je parlais d'un autre serveur au comportement normal. En fait, il s'agissait de mon serveur de test et j'avais essayé directement avec lynx sans passer par un poste client, essai que je n'avais pas encore fait sur le serveur en prod. Un essai ultérieur m'a confirmé que j'ai bien le même problème sur mon serveur de test.

[jibe]

Hello,

Finalement, j'ai trouvé ce rapport de bug et cet autre. C'est bien mon cas ! Je m'étonne simplement que pour moi, squid ne résolve pas le problème.

Y-a-t-il eu une solution de donnée ? Je n'en vois pas trace, seulement quelques indications pour mieux localiser le problème ?

[jibe]

Salut,

Bon, alors, bug non encore résolu, ou problème de config de ma part ?

Mais dans le second cas, où donc ai-je fait une c*** ?

[jibe]

Salut,

Je viens d'avoir une info pour le moins curieuse : le https fonctionnerait bien avec Internet Explorer, mais pas avec Mozilla...

L'info me parait fiable, mais je n'ai pas pu vérifier, n'ayant pas accès à une ligne numéris. Par contre, ce qui parait très curieux est que cela reste lié à une connection numéris par carte ISDN interne...