Https ne passe plus : derrière une passerelle

Support Debian
#1

Salut,
Il m’arrive un truc incompréhensible, je ne me l’explique pas…
Hier encore ça fonctionnait.

Je n’arrive plus a naviguer en https sur mon LAN… time out.
J’ai été oblige de faire un tunnel ssh vers ma passerelle pour venir ici…

La passerelle:

  • Squid sans authentification
  • iptables-save:

[code]# Generated by iptables-save v1.4.12 on Fri Mar 1 19:42:24 2013
*raw
:PREROUTING ACCEPT [10964864:14461848356]
:OUTPUT ACCEPT [6100182:1867895842]
COMMIT

Completed on Fri Mar 1 19:42:24 2013

Generated by iptables-save v1.4.12 on Fri Mar 1 19:42:24 2013

*nat
:PREROUTING ACCEPT [15513:1166435]
:INPUT ACCEPT [9742:631799]
:OUTPUT ACCEPT [77076:4662857]
:POSTROUTING ACCEPT [59470:3596975]
-A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128
-A POSTROUTING -o ppp0 -j MASQUERADE
COMMIT

Completed on Fri Mar 1 19:42:24 2013

Generated by iptables-save v1.4.12 on Fri Mar 1 19:42:24 2013

*filter
:INPUT DROP [1102:622052]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [6094562:1867523190]
:fail2ban-dovecot-pop3imap - [0:0]
:fail2ban-pureftpd - [0:0]
:fail2ban-ssh - [0:0]
-A INPUT -p tcp -m multiport --dports 21 -j fail2ban-pureftpd
-A INPUT -p tcp -m multiport --dports 110,995,143,993 -j fail2ban-dovecot-pop3imap
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 10.10.10.0/24 -j ACCEPT
-A INPUT -i eth0 -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A FORWARD -i ppp0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o ppp0 -j ACCEPT
-A fail2ban-dovecot-pop3imap -j RETURN
-A fail2ban-pureftpd -j RETURN
-A fail2ban-ssh -j RETURN
COMMIT

Completed on Fri Mar 1 19:42:24 2013

Generated by iptables-save v1.4.12 on Fri Mar 1 19:42:24 2013

*mangle
:PREROUTING ACCEPT [10964864:14461848356]
:INPUT ACCEPT [10859024:14431292723]
:FORWARD ACCEPT [104683]
:OUTPUT ACCEPT [6100182:1867895842]
:POSTROUTING ACCEPT [6205597:1897935518]
COMMIT

Completed on Fri Mar 1 19:42:24 2013[/code]

Rien de particulier sur le client

-P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT

J’ai une poutre dans l’oeil que je ne vois pas…
Si vous pouviez me mettre sur la voie ce serait sympa (j’ai eu une journée difficile - j’ai du réinstaller ma Sid… partition btrfs cassée, pas d’internet pour télécharger les outils - rupture de fibre entre 08h00 et 16h… je suis plutôt énervé. Je sais c’est pas votre problème, mais ça fait du bien de le dire…). :wink:

j’ai bien regardé avec tcpdump, mais c’est un peu indigeste, tout ce que j’ai remarqué, c’est pas mal de lenght 0. Si ça vous parle ?

Merci d’avance! :smiley:

#2

Le trafic HTTPS traverse la passerelle sans passer par squid ?
D’autres protocoles sont-ils affectés ou HTTPS est-il le seul ?
A quelle étape se produit le time-out ? A l’établissement de la connexion TCP ou plus tard lors de l’échange de données ? Tu peux tester avec des outils en ligne de commande comme tcptraceroute, telnet, nc ou wget qui te donneront de meilleurs messages d’erreur qu’un navigateur.
Je vois que ta connexion internet est une interface PPP, si PPPoE c’est peut-être un problème de MTU ? Essaie de le baisser sur ton poste client pour voir si ça passe.

#3

Bien vu le MTU. :038

Je pensais que ça ne concernait que la machine qui se connectait en pppoe, pas les clients.

Bon, ce qui me gène… C’est de devoir configurer tous les appareils/dispositifs de mon LAN…
Il ne suffirait pas que je baisse le MTU de l’interface serveur connectée au lAN pour que le pb soit réglé ?

Merci beaucoup!
Tu m’as redonné de la sérénité… 8)

Edit, il m’est arrivé un truc bizarre avec le fichier interfaces:
Ma machine refuse le netmask:

# ifup eth1 Error: an inet prefix is expected rather than "10.10.10.101/255.255.225.0". Failed to bring up eth1.
Mais ça passe sous cette forme:

[code] address 10.10.10.101/32

netmask 255.255.225.0[/code]

C’est la première fois que je vois ça… :017

Edit2: D’autres protocoles étaient touchés, je m’en rends compte maintenant… les mails arrivent convenablement, les sessions ssh n’échouent plus lamentablement, etc… Encore merci!

#4

Salut et suite…

J’ai passé ma connexion PPPoE avec un MTU de 1492. Ça ne change rien.
Je m’en doutais un peu, avant que je passe ma box en mode bridge j’avais vérifié la configuration et le (la ?) MTU était à 1500.

Donc, sur le serveur j’ai un MTU sur le PPPoE de 1492, et 1500 sur eth0.
Si je met le MTU à 1500 sur le client, plein de paquets ne reviennent pas…
Si je met le MTU à 1492 tout fonctionne convenablement.

Passerelle:

[code]$ /sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 90:2b:34:14:1d:36
inet adr:10.10.10.1 Bcast:10.10.10.255 Masque:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Packets reçus:814154 erreurs:0 :0 overruns:0 frame:0
TX packets:472691 errors:0 dropped:0 overruns:0 carrier:1
collisions:0 lg file transmission:1000
Octets reçus:1108675592 (1.1 GB) Octets transmis:114422433 (114.4 MB)

eth1 Link encap:Ethernet HWaddr 00:40:f4:ca:6c:ba
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Packets reçus:61867 erreurs:0 :1 overruns:0 frame:0
TX packets:49732 errors:0 dropped:0 overruns:3 carrier:0
collisions:0 lg file transmission:1000
Octets reçus:62983838 (62.9 MB) Octets transmis:6594163 (6.5 MB)

lo Link encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
Packets reçus:10123 erreurs:0 :0 overruns:0 frame:0
TX packets:10123 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
Octets reçus:1327200 (1.3 MB) Octets transmis:1327200 (1.3 MB)

ppp0 Link encap:Protocole Point-à-Point
inet adr:41.207.43.232 P-t-P:41.207.43.1 Masque:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
Packets reçus:61085 erreurs:0 :0 overruns:0 frame:0
TX packets:49071 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:3
Octets reçus:61582743 (61.5 MB) Octets transmis:5468338 (5.4 MB)
[/code]

Cient:

[code]/sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 00:15:e9:b5:69:26
inet adr:10.10.10.101 Bcast:10.10.10.101 Masque:255.255.255.255
adr inet6: fe80::215:e9ff:feb5:6926/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1492 Metric:1
RX packets:39342 errors:0 dropped:0 overruns:0 frame:0
TX packets:28498 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:40262178 (38.3 MiB) TX bytes:3412492 (3.2 MiB)
Interruption:19

lo Link encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)[/code]

#5

Au contraire, cela concerne toutes les machines qui communiquent à travers le lien PPPoE. La machine directement connectée a un avantage : elle connaît la valeur de MTU du lien, ce qui lui permet d’annoncer la bonne valeur de MSS à ses pairs TCP, contrairement aux machines qui sont derrière. C’est pourquoi les communications relayées par le proxy squid ou le tunnel SSH n’étaient pas impactées.

Le MTU sur le réseau local est 1500, donc les machines du LAN utilisent cette valeur pour calculer la taille maximum des paquets qu’elle envoient et des segments TCP qu’elles peuvent recevoir (MSS) annoncée aux pairs lorsqu’elles établissent une connexion TCP. Si une machine du LAN envoie un paquet de 1500 octets vers l’extérieur, pas de problème : la machine qui fait routeur sait que le MTU du lien PPPoE est de 1492 et va soit fragmenter le paquet en deux ou bien, si le paquet a l’indicateur “do not fragment”, renvoyer un message d’erreur ICMP “packet too big” à l’émetteur en indiquant la taille maximum admissible, que l’émetteur pourra utiliser pour renvoyer les données en les fragmentant ou en les segmentant.

Dans le sens descendant vers toi, le même principe s’applique de façon symétrique. Mais la différence est que tu ne contrôles rien ! Il arrive que le dernier routeur avant le lien PPPoE ne connaisse pas le MTU, par exemple parce que c’est un autre équipement qui s’occupe de l’encapsulation des paquets PPP dans PPPoE. Ou bien qu’il n’envoie pas les paquets ICMP “packet too big”, ce qui est très mal. Ou bien que ces paquets soient filtrés en chemin, ou bien que l’émetteur du paquet trop gros n’en tienne pas compte, ce qui est aussi mal. Conséquence dans tous ces cas : tu ne reçois pas les gros paquets.

Pour plus de détails, tu peux recherche “trou noir de MTU” ou an anglais “MTU black hole”, problème bien connu en PPPoE. Il y a eu des extensions pour que PPPoE puisse utiliser un MTU à 1500 donc avec un MTU ethernet à 1508, mais il faut que toute la chaîne le supporte (interface ethernet, modem, FAI).

Bref, l’idéal est de faire en sorte que les machines extérieures avec qui tu communiques n’envoient pas de paquets plus gros que 1492. Pour les communications utilisant le protocole TCP, on peut exploiter la valeur du champ MSS (maximum segment size) qui est transmis dans le paquet SYN envoyé à l’autre machine lors de l’établissement de chaque connexion TCP. Cette valeur est calculée à partir de la valeur de MTU de l’interface de sortie, c’est pourquoi diminuer celle-ci a contourné le problème.

[quote=“lol”]Bon, ce qui me gène… C’est de devoir configurer tous les appareils/dispositifs de mon LAN…
Il ne suffirait pas que je baisse le MTU de l’interface serveur connectée au LAN pour que le pb soit réglé ?[/quote]
Non, bien au contraire, ça pourrait que causer d’autres problèmes.
Il existe d’autres possibilités que le réglage manuel du MTU sur tous les postes du LAN pour baisser le MSS annoncé.
Pour les machines configurées en DHCP, il y a l’option “interface-mtu”. Vérifier quand même si les différents clients en tiennent compte.
Tu préfèreras peut-être ajouter sur ta passerelle une règle iptables avec “-j TCPMSS --clamp-mss-to-pmtu” pour modifier à la volée la valeur de MTU des paquets SYN qui la traversent. Elle est mentionnée dans la page de manuel d’iptables :

Deux avertissements :

  • Baisser le MTU ou le MSS n’est efficace qu’avec le protocole TCP.
  • Si tu utilises IPv6, le problème se pose aussi et il faut une règle ip6tables ou spécifier le MTU annoncé par le démon radvd.

255.255.225.0 n’est pas une valeur de masque valide. Tu voulais peut-être écrire 255.255.255.0 (/24), ou 255.255.224.0 (/19) ?

Tu es sûr que tu veux /32, soit un masque 255.255.255.255 ?

Comment ça, tu as passé à 1492 ? Ce n’était pas déjà le cas par défaut ? Il le faut sinon entre autres la règle iptables sus-mentionnée ne sera pas efficace.

#6

Salut et merci,
La règle iptables fonctionne parfaitement.

Pas de modification du dhcp, j’ai des périphériques à ip fixes (des caméras IP par ex) pour lesquels je ne peux changer la valeur du MTU. Mais c’est bon à savoir!
Je n’utilise pas IPv6 sur mon LAN, le réseau malgache ne le supporte pas encore; C’est donc une modification inutile pour l’instant. C’est dommage, j’aurais bien fait la bascule…

[quote]Tu voulais peut-être écrire 255.255.255.0 (/24)[/quote]Evidemment. Hier, n’était pas mon jour. c’est rectifié et évidemment ça fonctionne…

[quote=“PascalHambourg”]Comment ça, tu as passé à 1492 ? Ce n’était pas déjà le cas par défaut ? Il le faut sinon entre autres la règle iptables sus-mentionnée ne sera pas efficace.[/quote]J’avais au début laissé 1500 car c’était le configuration de la box quand elle était en mode passerelle. En laissant à 1500 et en mettant le client à 1492 ça fonctionnait.
Mais si c’est un problème pour la règle iptables, alors je laisse à 1492.

Merci pour toutes ces précisions c’est plus clair maintenant. Je n’ai pas l’habitude du PPPoE c’est une des premières fois ou je m’en sert. Comme il n’y a pas la possibilité d’ajouter des routes persistantes (elles s’effacent à chaque boot) à ma BOX (qui n’est pas dans le sous-réseau de mon LAN) j’ai décidé de la court-circuiter et de la mettre en mode bridge, donc PPPoE sur la passerelle.

Bref, résolu, et merci! :smiley:
Je peux retourner à (la confection de) ma terrine de lapin… :wink:

#7

Moi, c’est le contraire. Quand j’ai découvert ce menu inconvénient, je l’ai remplacé par PPPoA.

Un complément sur mon avertissement : le contournement n’est efficace que pour TCP, donc pas pour les protocoles autres que TCP susceptibles d’envoyer de gros paquets ; c’est notamment le cas de tout ce qui est VPN et tunnels basés sur UDP comme OpenVPN ou sur les protocoles d’encapsulation : IPIP (IPv4 dans IPv4, protocole IP 4), 6in4 (IPv6 dans IPv4, protocole IP 41) , GRE (protocole IP 47) et son dérivé PPTP, ESP et AH d’IPSec (protocoles IP 50 et 51)… Certains de ces protocoles permettent d’annoncer la valeur de MTU, mais il n’y a pas de solution globale.

EDIT: Si IPv6 t’intéresse il existe des fournisseurs de tunnels (tunnel brokers) indépendants des FAI, dont les plus connus sont SixXS et Hurricane Electric. Cependant comme indiqué ci-dessus ces tunnels sont affectés par le problème de MTU.

#8

Hum tu m’ouvre des horizons…
Je viens de lire quelques papiers sur PPPoA et ça à l’air pas mal (meilleure encapsulation si j’ai bien compris). Si tu l’utilise il doit y avoir une bonne raison…
Dans les paramètres de ma BOX, avant que je la passe ne bridge, j’ai remarqué ces paramètres: VPI/VCI : 8/35 qui correspondraient à des paramètres PPPoA ?
Je vais demander confirmation à mon FAI et tenter un passage à PPPoA.

Edit: Ben non PPPoE seulement… :12

#9

Ici en France (métropolitaine), la plupart des FAI qui utilisent PPP en ADSL supportent indifféremment PPPoE ou PPPoA sur le même VPI/VCI, 8/35 en général. Free dégroupé n’utilise pas PPP, sur le canal 8/36.

La surcharge d’encapsulation de PPPoA est effectivement moindre que PPPoE, mais comme déjà dit le gros avantage pour lequel je le préfère est qu’il permet d’utiliser la valeur de MTU standard 1500 et n’est pas limitée à 1492 comme PPPoE. Dans un internet parfait une valeur de 1492 ne serait pas gênante, mais voilà, l’internet n’est pas parfait et cette valeur pose parfois des problèmes comme tu l’as constaté.

L’inconvénient de PPPoA, c’est qu’on ne peut pas l’utiliser avec un modem en mode bridge ethernet car PPP, qui suppose une liaison point à point, ne peut être transporté directement sur un réseau ethernet qui est par essence multipoint. PPPoE a précisément été conçu pour cela : transporter du PPP sur ethernet.

Pour pouvoir utiliser PPPoA avec un modem qui ne fasse pas routeur intégré, il faut soit :

  • un modem ethernet pouvant fonctionner comme relais entre PPPoA et un protocole de transport de PPP qui peut passer sur de l’ethernet, comme PPTP (c’est le cas de mon modem principal, un vieil Alcatel Speed Touch Home) ;
  • un modem ethernet qui gère la session PPPoA mais affecte par DHCP et route l’adresse IP publique vers la machine qui qui est connectée dessus (cas de la freebox sur ligne non dégroupée et de certains modems-routeurs) ;
  • un modem USB avec émulation ATM (c’est le cas de mon modem de secours, un petit Sagem F@st 80) ;
  • un modem et un routeur avec une interface ATM (c’est le cas de mon modem principal que j’ai fait fonctionner avec un routeur Cisco 1401 pour voir, mais je préfère ma passerelle Linux).
#10

Internet n’est pas parfait, c’est peu de le dire. Et comme chaque FAI fait sa petite sauce avec nos paquets, c’est vrai qu’il vaut mieux rester sur des standards.
J’ai un ou deux vieux modems qui traînent, je vais farfouiller dans mes 3 cantines de vieilleries et essayer de mettre la main dessus pour faire des essais. Point de vue vitesse, pas de risque de limitation à cause du modem ?
je pense que le Directeur Technique de mon FAI m’a dit pas de PPPoA, sous entendu “avec notre box”… Reste à tester.

#11

Ça dépend du modem, de la ligne et de l’abonnement, bien sûr. Si tu as une ligne courte de bonne qualité en ADSL2+ et que tu branches dessus un vieux modem qui ne supporte que l’ADSL de base, le débit de synchroisation sera nettement inférieur à celui obtenu en ADSL2+.

#12

Salut,

Je dois avoir 3 modems qui traînent… Une carte pci, un modem usb (genre “stick”) et un plus vieux qui se branche sur un port com (que je n’ai pas… il me faut un adaptateur).
Je pense qu’ils sont tous “ATM”. Je vais faire des essais avec les trois, je donnerais un retour.

Si je me passe complètement de la Box je serais ravi…
C’est agaçant d’avoir à sa disposition un matériel moderne “bridé”, pleins d’options sont inaccessibles (je suppose pour empêcher le tout venant de tripatouiller dedans…).
Evidemment pas moyen de trouver le modèle exact de ma box (c’est du sur mesure, les specs sont cachées) donc pas de firmware débridé à télécharger…

#13

Le modem avec port série RS232 (“COM”) n’est certainement pas un modem ADSL mais un simple modem téléphonique (RTC) V.90 (56 kbit/s) ou moins. Les autres aussi, peut-être. Il faut vérifier le modèle. A noter qu’on ne trouve pas toujours facilement des pilotes et firmwares pour les modems PCI et USB.

Tu peux au moins la passer en bridge et gérer la session PPP, l’adresse IP publique, la NAT et le filtrage toi-même. Ici la majorité des box propriétaires des FAI ne le permettent pas.

#14

Salut,
Oui je viens de me rendre compte que c’est pas si évident à configurer…
Si je n’y arrive pas j’ouvre un autre sujet, mais Internet regorge de papiers (plus ou moins utiles) je devrais m’en sortir.

Une dernière question, faut-il avoir un n° de téléphone pour une connexion adsl par modem ?

#15

C’est pour cela que les FAI fournissent des box avec une configuration et des options de base, pour faciliter la vie du grand public. Mais c’est forcément limité et ne peut pas convenir à tout le monde, c’est comme la différence entre le prêt-à-porter et le sur mesure.

Techniquement non. On appelle cela “ADSL nu” si l’ADSL (je parle juste de la partie ADSL et pas de l’accès internet) est fourni par l’opérateur qui gère la paire de cuivre et la téléphonie classique “RTC” (souvent l’opérateur historique, comme France Telecom en France), ou bien “dégroupage total” si l’ADSL est fourni par un opérateur tiers. Mais la disponibilité de ce type de connexion dépend des offres commerciales des FAI et opérateurs ; en France métropolitaine cela n’a pas toujours existé.

#16

Merci pour toutes ces précisions.
Tous mes modems sont des 56k y compris la carte pci… Ça va pas la faire.
Je vais voir si j’ai pas des copains qui ont un modem qui m’irais dans leurs cartons…

#17

Salut,

Et effectivement…

Mon Mar 11 08:37:08 2013 TLS Error: Unroutable control packet received from [AF_INET]41.188.26.122:2194 (si=3 op=P_CONTROL_V1) Mon Mar 11 08:37:08 2013 TLS Error: Unroutable control packet received from [AF_INET]41.188.26.122:2194 (si=3 op=P_CONTROL_V1) Mon Mar 11 08:37:10 2013 TLS Error: Unroutable control packet received from [AF_INET]41.188.26.122:2194 (si=3 op=P_CONTROL_V1) Mon Mar 11 08:37:10 2013 TLS Error: Unroutable control packet received from [AF_INET]41.188.26.122:2194 (si=3 op=P_CONTROL_V1) Mon Mar 11 08:37:10 2013 TLS Error: Unroutable control packet received from [AF_INET]41.188.26.122:2194 (si=3 op=P_CONTROL_V1) Mon Mar 11 08:37:10 2013 TLS Error: Unroutable control packet received from [AF_INET]41.188.26.122:2194 (si=3 op=P_CONTROL_V1) Mon Mar 11 08:37:10 2013 TLS Error: Unroutable control packet received from [AF_INET]41.188.26.122:2194 (si=3 op=P_ACK_V1) ...

Je passe en TCP.

#18

Le passage en TCP résoud le problème ? D’après une recherche rapide, ce message d’erreur semble plutôt provoqué par un décalage d’horloge entre client et serveurn ou un problème de certificat.

Note aussi que l’utilisation de TCP pour le transport d’un VPN n’est pas optimale, car en plus de la segmentation TCP impose des exigences inutiles voire nuisibles pour ce type d’application : acquittement, retransmission, remise dans l’ordre (ce qui implique que si un paquet est perdu tous les suivants sont mis en attente tant qu’il n’a pas été retransmis et reçu, même s’ils font partie de communications différentes).

#19

Salut,

[quote=“PascalHambourg”]Le passage en TCP résoud le problème ?[/quote]Ça passe bien en tcp. Pour ce que j’en ai essayé (ouverture du serveur Web distant dans un navigateur) ça fonctionne bien.
J’ai une mauvaise connexion en ce moment, je ne peux pas essayer des trucs lourds comme un bureau à distance. Dés que c’est possible je ferais un essai (histoire de vérifier les effets secondaires du tcp…).

je n’ai peut-être pas pris les bonnes lignes de logs d’openvpn, mais c’est la première fois que j’avais ce genre de ligne (jamais vu en udp).

#20

Si tu ne fais passer qu’une seule connexion à la fois à travers le VPN et que le taux de perte de paquets reste minime, alors les effets indésirables du transport par TCP ne devraient pas être perceptibles. Le problème est plus apparent quand il y a plusieurs connexions en parallèle à travers le VPN : un paquet perdu bloque toutes les connexions et pas seulement celle à laquelle le paquet perdu appartient. Très sympa quand on a des applications interactives.