Re: [TECH] [FRnOG] [MISC] Erreur HTTP 408
Bonjour, Ce qui est bizarre c'est que la requête HTTP est envoyée à moitié dans le paquet 6 (81 octets) et à moitié dans le paquet 8 (44 octets) alors que la carte indus annonce un MSS de 536. La carte aurait pu mettre toutes les données dans un seul paquet. C'est peut-être une piste... Cordialement, Thomas 24 déc. 2023 13:14:04 Stéphane Rivière : > Boujour et bon courage à celles et ceux de permanence ou d'astreinte :) > > > Si quelqu'un a une idée ou a déjà rencontré un cas similaire... j'avoue être > en manque d'inspiration... > > C'est pour une application avec des cartes industrielles (PIC 32 bits, codage > en C, utilisation des stacks et libs MICROCHIP) reliées à des routeurs 4G (la > même manip que le message sur les QRC). > > Rien d'extravaguant. Tout étant implémenté, avec OpenVPN, un proxy Nginx en > frontal et un serveur HTTP GET/POST basique implémenté en Ada par mes soins. > > Je me retrouve avec des erreurs 408 (timout au niveau du proxy Nginx) > *uniquement avec la carte indus* (qui envoie juste une URL GET similaire à > celle ci-dessous). > > *Aucune erreur si j'envoie par FF une URL similaire : > *172.31.0.1:8081/231224111955085123030004062C3031323353616C7574206C657320706F7465733738396342?* > * > > 172.31.0.3 - - [24/Dec/2023:11:19:37 +0100] "GET > /231224111843085123030003062C3031323353616C7574206C657320706F7465733738391F5C? > HTTP/1.1" *408* 0 "-" "-" < la *carte indus* > 172.31.0.3 - - [24/Dec/2023:11:20:48 +0100] "GET > /231224111955085123030004062C3031323353616C7574206C657320706F7465733738396342? > HTTP/1.1" *408* 0 "-" "-"< *la carte indus* > 172.31.0.2 - - [24/Dec/2023:11:36:58 +0100] "GET > /231224111955085123030004062C3031323353616C7574206C657320706F7465733738396342? > HTTP/1.1" 404 6 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:103.0) > Gecko/20100101 Firefox/103.0" > 172.31.0.2 - - [24/Dec/2023:11:37:10 +0100] "GET > /231224111955085123030004062C3031323353616C7574206C657320706F7465733738396342? > HTTP/1.1" 404 6 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:103.0) > Gecko/20100101 Firefox/103.0" > 172.31.0.2 - - [24/Dec/2023:11:37:12 +0100] "GET > /231224111955085123030004062C3031323353616C7574206C657320706F7465733738396342? > HTTP/1.1" 404 6 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:103.0) > Gecko/20100101 Firefox/103.0" > > > En utilisant Tshark pour se brancher sur le VPN, filtrer les paquets TCP sur > le port 8081 pour des trames HTTP uniquement. > > *Essai avec FF : OK - *avec l'URL > 172.31.0.1:8081/231224111955085123030004062C3031323353616C7574206C657320706F7465733738396342?* > * > > Tshark *détecte le trafic comme étant bien des trames HTTP* : voir en gras > ci-dessous* > * > > root@* /etc/openvpn >tshark -i tun0 -d tcp.port==8081,http -f "port 8081" > Running as user "root" and group "root". This could be dangerous. > Capturing on 'tun0' > 1 0.0 172.31.0.2 ? 172.31.0.1 TCP 52 55372 ? 8081 [ACK] Seq=1 > Ack=1 Win=501 Len=0 TSval=2641523022 TSecr=3450216110 > 2 0.47455 172.31.0.1 ? 172.31.0.2 TCP 52 [TCP ACKed unseen > segment] 8081 ? 55372 [ACK] Seq=1 Ack=2 Win=66 Len=0 TSval=3450226350 > TSecr=2641492368 > 3 0.807369694 172.31.0.2 ? 172.31.0.1 *HTTP* 489 [TCP Previous segment > not captured] GET > /231224111955085123030004062C3031323353616C7574206C657320706F7465733738396342? > HTTP/1.1 > 4 0.814896905 172.31.0.1 ? 172.31.0.2 *HTTP* 205 [TCP ACKed unseen > segment] HTTP/1.1 404 Not Found (text/plain) > > La transaction se limite à 4 lignes. *RAS... > * > > * > * > > *Essai avec la carte indus : KO* - on dirait que la pile TCP/IP pose problème > mais ce ne sont que des suppositions, je ne peux pas déverminer coté carte. > > Tshark*ne détecte pas de trame HTTP* > > J'ai rayé le trafic concernant le PC portable > > root@* /etc/openvpn >tshark -i tun0 -d tcp.port==8081,http -f "port 8081" > Running as user "root" and group "root". This could be dangerous. > Capturing on 'tun0' > 1 0.0 172.31.0.2 ? 172.31.0.1 TCP 52 55372 ? 8081 [ACK] Seq=1 > Ack=1 Win=501 Len=0 TSval=2641574990 TSecr=3450268108 > 2 0.48117 172.31.0.1 ? 172.31.0.2 TCP 52 [TCP ACKed unseen > segment] 8081 ? 55372 [ACK] Seq=1 Ack=2 Win=67 Len=0 TSval=3450278328 > TSecr=2641523888 > / 3 1.486198007 172.31.0.3 ? 172.31.0.1 TCP 44 1032 ? 8081 [SYN] Seq=0 > Win=1200 Len=0 MSS=536 > 4 1.486247826 172.31.0.1 ? 172.31.0.3 TCP 44 8081 ? 1032 [SYN, ACK] > Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 > 5 1.526477917 172.31.0.3 ? 172.31.0.1 TCP 40 1032 ? 8081 [ACK] Seq=1 > Ack=1 Win=1200 Len=0 > 6 1.534424273 172.31.0.3 ? 172.31.0.1 TCP 121 1032 ? 8081 [PSH, ACK] > Seq=1 Ack=1 Win=1200 Len=81 [TCP segment of a reassembled PDU] > 7 1.534506612 172.31.0.1 ? 172.31.0.3 TCP 40 8081 ? 1032 [ACK] Seq=1 > Ack=82 Win=65535 Len=0/ > 8 1.534556251 172.31.0.3 ? 172.31.0.1 *TCP* 84 GET > /231224121420085123030006062C3031323353616C7574206C657320706F746573373839C50E? >
Re: [FRnOG] [TECH] MTU sur switch Huawei CE
Ou bien : payload icmp + header icmp + header ip + header ethernet avec tag VLAN (ajouté en interne uniquement) 9170 + 8 + 20 + 14 + 4 = 9216 Thomas 15 déc. 2023 17:32:30 Paul Rolland (ポール・ロラン) : > Hello, > > On Fri, 15 Dec 2023 17:20:57 +0100 > Laurent-Charles FABRE wrote: > >> Switch 1 : >> Route Port,The Maximum Transmit Unit is 9600,The Maximum Frame Length is >> 9216 > >> Le plus gros paquet que je passe: >> ping -f -s 9170 10.0.61.75 >> PING 10.0.61.75: 9170 data bytes, press CTRL_C to break >> Reply from 10.0.61.75: bytes=9170 Sequence=1 ttl=254 time=1 ms >> >> Y'a un truc qui m'échappe >> Qui saurait me dire pourquoi 9170 ? > > Maximum frame, c'est cote Ethernet ca, non ? > Donc, tu as: > 9170 octets de data ICMP + 8 octets de header ICMP + 20 octets de header IP > soit 9198 octets... pour arriver a 9216, il te faut encore 18 octets : > - 6 de dest mac, > - 6 de src mac, > - 2 d'ether type > - 4 de fcs > > Ca doit ca a peu pres... > > Mais comme tu as ecrit, c'est le bon jour pour passer pour une buse ;) > > Paul > > -- > Paul Rolland E-Mail : rol(at)witbe.net > CTO - Witbe.net SA Tel. +33 (0)1 47 67 77 77 > 18 Rue d'Arras, Bat. A11 Fax. +33 (0)1 47 67 77 99 > F-92000 Nanterre RIPE : PR12-RIPE > > Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un > navigateur "Some people dream of success... while others wake up and work > hard at it" > > "I worry about my child and the Internet all the time, even though she's > too young to have logged on yet. Here's what I worry about. I worry that 10 > or 15 years from now, she will come to me and say 'Daddy, where were you > when they took freedom of the press away from the Internet?'" > --Mike Godwin, Electronic Frontier Foundation > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] Mise en œuvre d'IPv6 dans les infrastructures mail
si ton OS détecte que tu as une stack IPv6 fonctionnelle et que ton DNS résout IPv6 (et pour http, que ton serveur répond en IPv6, si non ca fallback en IPv4 au bout de quelques secondes), alors c'est toujours IPv6 qui sera utilisé, même si ca résout aussi en IPv4(IPv6 est toujours prioritaire sur IPv4). Ce n'est pas vrai non plus. Cela dépend de la configuration du système d'exploitation (et, parfois, de l'application). La configuration par défaut est souvent de privilégier IPv6 mais c'est modifiable (même sur Windows !) Salut, En complément : https://www.rfc-editor.org/rfc/rfc6724#section-6 En lisant l'algorithme de sélection de l'adresse IP de destination, j'ai réalisé que, depuis le début, je ne comprenais pas vraiment le fonctionnement du round-robin DNS (lorsque, à chaque requête, le serveur DNS renvoie une liste d'adresses IP dans un ordre aléatoire). Cette RFC est donc très importante à mes yeux. Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Serveur DNS employés ?
Salut Christophe, "Si on veut un lag en dessous de quelques secondes, il faut autre chose (anycast BGP, ou SPOF ultra-redondé où on met un load balancer). " Pour le "SPOF utra-redondé", tu fais allusion à un cluster de load balancer étendu ou pas à plusieurs sites; un seul cluster = SPOF c'est bien ça ? Je demande cela car je pense que l'utilisation d'un seul cluster (load balancer, firewall ou autre) ne permet pas de rendre hautement disponible une application (un cluster = un SPOF selon moi). Cordialement, Thomas On 15/12/2022 13:00, Christophe Desnoyer wrote: Je confirme (pour l'avoir expérimenté à grande échelle dans une autre vie) qu'un TTL DNS en dessous de 30 secondes, c'est pour se donner l'illusion qu'on aura une bascule instantanée dans un scénario de failover (ou de load balancing). En pratique, ça met plusieurs minutes à commuter. Mais cela dit, la commutation de DNS avec un TTL aussi bas que possible reste solution acceptable.. de dernier recours. Si on veut un lag en dessous de quelques secondes, il faut autre chose (anycast BGP, ou SPOF ultra-redondé où on met un load balancer). Le 15/12/2022 à 12:51, Pierre-Henry Muller via frnog a écrit : Email Signature Le 14/12/2022 à 10:23, Pascal PETIT a écrit : il y a 2 questions que je me pose : - y a-t-il des gens qui utilisent le DNS pour faire de la tolérance de panne avec un TTL très très court et une mise à jour du dns en cas de soucis ? (je pense que c'est une très mauvaise idée) orange.fr, facebook.com 60 secondes www.google.com, yahoo.fr 300 secondes Ils sont bien plus nombreux qu'on le pense, même si pour Google c'est à mon avis plus une raison de traçabilité. - et, en défense contre les TTL trop courts, y a-t-il une durée mini que les dns récursifs des FAI imposent ? Tous ceux qui font du DNS menteur sont ceux qui imposent un TTL minimum. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Censure ?
Salut, Je pense qu'on est sur un cas de DNS menteur : mon opérateur me renvoie 127.0.0.1 et d'autres serveurs répondent correctement. Il s'agit peut-être d'une directive des autorités. Cordialement, Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
