Forum Linux.debian/ubuntu connexion squid www.edf.com ou www.edf.fr impossible (Résolu)

Posté par  . Licence CC By‑SA.
Étiquettes :
1
15
avr.
2013

Bonjour,

Nous n'arrivons pas à nous connecter sur le site de edf.com avec les postes clients.

Voici notre architecture:

Nous avons un serveur debian qui est le squid dans lequel est paramétré un squidguard. Concernant les flux réseaux nous avons un Arkoon qui gère les ouvertures des ports.

voici mes tests depuis le serveur squid
‰ping www.google.com
OK
‰ping www.edf.com
NOK

‰wget www.google.com
OK
‰wget www.edf.com
NOK

Mais
‰lynx http://www.edf.com
OK

je ne comprend pas pourquoi je peux naviguer avec le navigateur lynx depuis le squid mais sur les postes de travail il est impossible de naviguer sur le site de edf.com
De plus nous n'avons aucunes acl ou blacklist qui filtre le site de edf.com.

Les acl sont mises à jour quotidiennement depuis le lien ftp://ftp.univ-tlse1.fr/pub/reseau/cache/squidguard_contrib/blacklists.tar.gz

voici les log lors squid lors de mes tests depuis un poste client.
…………………………………………………………………………………………………………………………………………………………………………………………………………
‰tail -f /var/log/squid3/access.log | grep -i "ip du poste client"

"ip du poste client" 50087 [15/Apr/2013:08:19:03 +0200] "GET http://www.edf.com/ HTTP/1.1" 93.188.170.54 - "USERAD" "/" 0 - 0i"-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C)" TCP_MISS:DIRECT
"ip du poste client" 50088 [15/Apr/2013:08:19:08 +0200] "GET http://www.edf.com/ HTTP/1.1" - - - "/" 407 text/html 4201i"-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C)" TCP_DENIED:NONE
"ip du poste client" 50088 [15/Apr/2013:08:19:08 +0200] "GET http://www.edf.com/ HTTP/1.1" - - - "/" 407 text/html 4539i"-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C)" TCP_DENIED:NONE
…………………………………………………………………………………………………………………………………………………………………………………………………………

Sur le Arkoon ne n'avons pas constaté de blockage de flux.

Nous avons effectué des recherches sur le net mais rien de concluant. Nous ne constatons rien d'anormal sur le squid

Si vous avez des idées elles sont les bienvenues!!!

  • # acl ?

    Posté par  (site web personnel) . Évalué à 1. Dernière modification le 15 avril 2013 à 10:01.

    Et si tout simplement tu désactives juste ton acl de filtrage dans squid ? Tu serras vite fixé
    Vu que tu as un DENY dans squid je ne pense pas que le pare-feu est un quelconque rapport, même si il faut toujours se méfier d'un Arkoon (quand il fonctionne)

    Oups j’oubliais, tu ne dis pas si les Wget et le lynx passent (ou pas) au travers du proxy, donc ça ne veux pas dire grand chose

    • [^] # Re: acl ?

      Posté par  . Évalué à 1.

      Je continu investir sur cette voie.

      Nous avons la règle suivante dans squid.conf

      acl denyfc1 url_regex -i .txt$

      et dans /etc/squid3/ nous avons le fichier suivant:

      allow_url_redir.txt avec la ligne suivante:
      .edf.com

      • [^] # Re: acl ?

        Posté par  (site web personnel) . Évalué à 1.

        Très bizarre, effectivement il y a des grandes chances qu'une partie du problème soit là, cependant il ne s'agit pas d'une conf par défaut il faudrait savoir pourquoi il y a cette acl.
        Ce qui m'étonne aussi c'est le ping, pour moi ça fonctionne sur www.edf.com (ip 93.188.170.54), il y a peut-être aussi une règle de filtrage sur le pare-feu ?

    • [^] # Re: acl ?

      Posté par  . Évalué à 1.

      J'ai effectué le test je n'ai pas eu de changement

    • [^] # Re: acl ?

      Posté par  . Évalué à 0.

      Nous avons effectué des tcpdump sur les cartes réseaux du squid et de l'Arkoon (lan et net)

      Emission depuis un poste client de www.edf.com

      Sur le squid
      root@ilmproxy01p:~# tcpdump -v | grep edf.com
      %tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
      192.168.56.56.41475 > ilmprtadc04cam.intra.ville-issy.fr.domain: 26870+ AAAA? www.edf.com. (29)
      ilmprtadc04cam.intra.ville-issy.fr.domain > 192.168.56.56.41475: 26870 1/0/0 www.edf.com. CNAME d3c-vip1-1.cname.edf-linkbynet.com. (74)
      192.168.56.56.41475 > ilmprtadc04cam.intra.ville-issy.fr.domain: 20834+ A? www.edf.com. (29)
      ilmprtadc04cam.intra.ville-issy.fr.domain > 192.168.56.56.41475: 20834 2/0/0 www.edf.com. CNAME d3c-vip1-1.cname.edf-linkbynet.com., d3c
      -vip1-1.cname.edf-linkbynet.com. A 93.188.170.54

      OU
      %tcpdump -nnv | grep 93.188.170.54

      192.168.56.56.34947 > 93.188.170.54.80: Flags [S], cksum 0x7a8b (correct), seq 1193964382, win 5840, options [mss 1460,sackOK,TS val 62156481 ecr 0,nop,wscale 7], length 0
      93.188.170.54.80 > 192.168.56.56.34947: Flags [S.], cksum 0xb3d7 (correct), seq 596931810, ack 1193964383, win 4260, options [mss 1420,nop,wscale 0,nop,nop,TS val 473368395 ecr 62156481,sackOK,eol], length 0
      192.168.56.56.34947 > 93.188.170.54.80: Flags [.], cksum 0x03ee (correct), ack 1, win 46, options [nop,nop,TS val 62156483 ecr 473368395], length 0
      192.168.56.56.34947 > 93.188.170.54.80: Flags [P.], cksum 0x033f (incorrect -> 0x7a52), seq 1:582, ack 1, win 46, options [nop,nop,TS val 62156483 ecr 473368395], length 581
      192.168.56.56.34947 > 93.188.170.54.80: Flags [P.], cksum 0x033f (incorrect -> 0x7a1e), seq 1:582, ack 1, win 46, options [nop,nop,TS val 62156535 ecr 473368395], length 581
      192.168.56.56.34947 > 93.188.170.54.80: Flags [P.], cksum 0x033f (incorrect -> 0x79b6), seq 1:582, ack 1, win 46, options [nop,nop,TS val 62156639 ecr 473368395], length 581
      192.168.56.56.34947 > 93.188.170.54.80: Flags [P.], cksum 0x033f (incorrect -> 0x78e6), seq 1:582, ack 1, win 46, options [nop,nop,TS val 62156847 ecr 473368395], length 581
      192.168.56.56.33789 > 93.188.170.54.80: Flags [P.], cksum 0x033f (incorrect -> 0x6f05), seq 1:582, ack 1, win 46, options [nop,nop,TS val 62156898 ecr 473318041], length 581
      192.168.56.56.34947 > 93.188.170.54.80: Flags [P.], cksum 0x033f (incorrect -> 0x7746), seq 1:582, ack 1, win 46, options [nop,nop,TS val 62157263 ecr 473368395], length 581
      192.168.56.56.34947 > 93.188.170.54.80: Flags [P.], cksum 0x033f (incorrect -> 0x7406), seq 1:582, ack 1, win 46, options [nop,nop,TS val 62158095 ecr 473368395], length 581
      192.168.56.56.34947 > 93.188.170.54.80: Flags [P.], cksum 0x033f (incorrect -> 0x6d86), seq 1:582, ack 1, win 46, options [nop,nop,TS val 62159759 ecr 473368395], length 581
      192.168.56.56.34947 > 93.188.170.54.80: Flags [P.], cksum 0x033f (incorrect -> 0x6086), seq 1:582, ack 1, win 46, options [nop,nop,TS val 62163087 ecr 473368395], length 581

      %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

      sur le Arkoon
      ./tcpdump -nnvi eth4 | grep -i 93.188.170.54
      Entrée
      %%%%%%
      eth4 pour le lan
      %%%%%%
      11:16:51.356220 IP (tos 0x0, ttl 64, id 31343, offset 0, flags [DF], length: 52) 192.168.56.56.57010 > ..http: . [tcp sum ok] ack 1 win 46
      11:16:51.367113 IP (tos 0x0, ttl 64, id 31344, offset 0, flags [DF], length: 633) 192.168.56.56.57010 > ..http: P 1:582(581) ack 1 win 46
      11:16:51.569103 IP (tos 0x0, ttl 64, id 31345, offset 0, flags [DF], length: 633) 192.168.56.56.57010 > ..http: P 1:582(581) ack 1 win 46
      11:16:51.977115 IP (tos 0x0, ttl 64, id 31346, offset 0, flags [DF], length: 633) 192.168.56.56.57010 > ..http: P 1:582(581) ack 1 win 46
      11:16:52.793148 IP (tos 0x0, ttl 64, id 31347, offset 0, flags [DF], length: 633) 192.168.56.56.57010 > ..http: P 1:582(581) ack 1 win 46
      11:16:54.425090 IP (tos 0x0, ttl 64, id 31348, offset 0, flags [DF], length: 633) 192.168.56.56.57010 > ..http: P 1:582(581) ack 1 win 46
      11:16:57.689105 IP (tos 0x0, ttl 64, id 31349, offset 0, flags [DF], length: 633) 192.168.56.56.57010 > ..http: P 1:582(581) ack 1 win 46
      11:17:04.217082 IP (tos 0x0, ttl 64, id 31350, offset 0, flags [DF], length: 633) 192.168.56.56.57010 > ..http: P 1:582(581) ack 1 win 46
      11:17:17.273053 IP (tos 0x0, ttl 64, id 31351, offset 0, flags [DF], length: 633) 192.168.56.56.57010 > ..http: P 1:582(581) ack 1 win 46
      11:17:43.385152 IP (tos 0x0, ttl 64, id 31352, offset 0, flags [DF], length: 633) 192.168.56.56.57010 > ..http: P 1:582(581) ack 1 win 46
      11:18:35.609106 IP (tos 0x0, ttl 64, id 31353, offset 0, flags [DF], length: 633) 192.168.56.56.57010 > ..http: P 1:582(581) ack 1 win 46

      %%%%%%

      Sortie
      eth3 interface pour le net
      %%%%%%
      10:52:15.906041 IP (tos 0x0, ttl 63, id 39673, offset 0, flags [DF], length: 52) voisin.59982 > ..http: . [tcp sum ok] ack 1 win 46
      10:52:15.906122 IP (tos 0x0, ttl 63, id 39674, offset 0, flags [DF], length: 633) voisin.59982 > ..http: P 1:582(581) ack 1 win 46
      10:52:16.108439 IP (tos 0x0, ttl 63, id 39675, offset 0, flags [DF], length: 633) voisin.59982 > ..http: P 1:582(581) ack 1 win 46
      10:52:16.516311 IP (tos 0x0, ttl 63, id 39676, offset 0, flags [DF], length: 633) voisin.59982 > ..http: P 1:582(581) ack 1 win 46
      10:52:17.332346 IP (tos 0x0, ttl 63, id 39677, offset 0, flags [DF], length: 633) voisin.59982 > ..http: P 1:582(581) ack 1 win 46
      10:52:18.964413 IP (tos 0x0, ttl 63, id 39678, offset 0, flags [DF], length: 633) voisin.59982 > ..http: P 1:582(581) ack 1 win 46
      10:52:22.228323 IP (tos 0x0, ttl 63, id 39679, offset 0, flags [DF], length: 633) voisin.59982 > ..http: P 1:582(581) ack 1 win 46
      10:52:28.756328 IP (tos 0x0, ttl 63, id 39680, offset 0, flags [DF], length: 633) voisin.59982 > ..http: P 1:582(581) ack 1 win 46
      10:52:41.812503 IP (tos 0x0, ttl 63, id 39681, offset 0, flags [DF], length: 633) voisin.59982 > ..http: P 1:582(581) ack 1 win 46
      10:53:07.924483 IP (tos 0x0, ttl 63, id 39682, offset 0, flags [DF], length: 633) voisin.59982 > ..http: P 1:582(581) ack 1 win 46
      10:54:00.148435 IP (tos 0x0, ttl 63, id 39683, offset 0, flags [DF], length: 633) voisin.59982 > ..http: P 1:582(581) ack 1 win 46
      10:55:01.331155 IP (tos 0x0, ttl 63, id 39684, offset 0, flags [DF], length: 52) voisin.59982 > ..http: F [tcp sum ok] 582:582(0) ack 1 win 46

      %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

      Je ne constate pas de blocage TCP.
      Néanmoins ce qui est bizard c'est que j'ai fait un test identique avec un site qui fonctionne, dans les logs nous avons bien la résolution des noms

      Depuis le poste client pageperso.free.fr
      %%%
      sur le squid
      %%%
      tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
      11:29:43.682712 IP (tos 0x0, ttl 64, id 48688, offset 0, flags [DF], proto TCP (6), length 60)
      192.168.56.56.59384 > perso168-g5.free.fr.www: Flags [S], cksum 0x01f3 (correct), seq 1967423900, win 5840, options [mss 1460,sackOK,TS val 63127468 ecr 0,nop,wscale 7], length 0
      11:29:43.687752 IP (tos 0x28, ttl 54, id 0, offset 0, flags [DF], proto TCP (6), length 52)
      perso168-g5.free.fr.www > 192.168.56.56.59384: Flags [S.], cksum 0xa9c8 (correct), seq 4097625732, ack 1967423901, win 5840, options [mss 1420,nop,nop,sackOK,nop,wscale 7], length 0
      11:29:43.687762 IP (tos 0x0, ttl 64, id 48689, offset 0, flags [DF], proto TCP (6), length 40)
      192.168.56.56.59384 > perso168-g5.free.fr.www: Flags [.], cksum 0x0115 (correct), ack 1, win 46, length 0

      %%%
      Sur l'Arkoon
      Entrée
      %%%%%%
      eth4 pour le lan
      %%%%%%
      11:29:43.673597 IP (tos 0x0, ttl 64, id 48688, offset 0, flags [DF], length: 60) 192.168.56.56.59384 > perso168-g5.free.fr.http: S 1967423900:1967423900(0) win 5840
      11:29:43.678576 IP (tos 0x28, ttl 54, id 0, offset 0, flags [DF], length: 52) perso168-g5.free.fr.http > 192.168.56.56.59384: S [tcp sum ok] 4097625732:4097625732(0) ack 1967423901 win 5840
      11:29:43.678670 IP (tos 0x0, ttl 64, id 48689, offset 0, flags [DF], length: 40) 192.168.56.56.59384 > perso168-g5.free.fr.http: . [tcp sum ok] ack 1 win 46
      11:29:43.678795 IP (tos 0x0, ttl 64, id 48690, offset 0, flags [DF], length: 807) 192.168.56.56.59384 > perso168-g5.free.fr.http: P 1:768(767) ack 1 win 46
      11:29:43.683555 IP (tos 0x28, ttl 54, id 13930, offset 0, flags [DF], length: 40) perso168-g5.free.fr.http > 192.168.56.56.59384: . [tcp sum ok] ack 768 win 58
      11:29:43.685195 IP (tos 0x28, ttl 54, id 13931, offset 0, flags [DF], length: 1460) perso168-g5.free.fr.http > 192.168.56.56.59384: . 1:1421(1420) ack 768 win 58
      %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
      Sortie
      eth3 interface pour le net
      %%%%%%
      11:29:43.673662 IP (tos 0x0, ttl 63, id 48688, offset 0, flags [DF], length: 60) voisin.60632 > perso168-g5.free.fr.http: S 1967423900:1967423900(0) win 5840
      11:29:43.678560 IP (tos 0x28, ttl 55, id 0, offset 0, flags [DF], length: 52) perso168-g5.free.fr.http > voisin.60632: S [tcp sum ok] 4097625732:4097625732(0) ack 1967423901 win 5840
      11:29:43.678680 IP (tos 0x0, ttl 63, id 48689, offset 0, flags [DF], length: 40) voisin.60632 > perso168-g5.free.fr.http: . [tcp sum ok] ack 1 win 46
      11:29:43.678826 IP (tos 0x0, ttl 63, id 48690, offset 0, flags [DF], length: 807) voisin.60632 > perso168-g5.free.fr.http: P 1:768(767) ack 1 win 46
      11:29:43.683548 IP (tos 0x28, ttl 55, id 13930, offset 0, flags [DF], length: 40) perso168-g5.free.fr.http > voisin.60632: . [tcp sum ok] ack 768 win 58
      11:29:43.684673 IP (tos 0x28, ttl 55, id 13932, offset 0, flags [DF], length: 155) perso168-g5.free.fr.http > voisin.60632: FP 1421:1536(115) ack 768 win 58
      11:29:43.685172 IP (tos 0x28, ttl 55, id 13931, offset 0, flags [DF], length: 1460) perso168-g5.free.fr.http > voisin.60632: . 1:1421(1420) ack 768 win 58
      %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

      Nous avons effectué un test sur un site interdit nous n'avons pas de trace avec tcpdump le squidguard filtre bien les sites prohibés.

      • [^] # Re: acl ?

        Posté par  (site web personnel) . Évalué à 1. Dernière modification le 18 avril 2013 à 18:49.

        Tu ajoutes l'option -n dans tcpdump qui supprime la résolution de nom dans la trace, donc normal

        Essaye ceci, côté net
        tcpdump -i eth3 -Xvvnns0 -w /tmp/edf.cap

        Ouvre ta trace dans wireshark comme ça tu auras tout le détail

        C'est toi ICI ? Si non tu utilises quoi comme version de Squid ?

        Et l'acls contenant edf c'était quoi ?

        • [^] # Re: acl ?

          Posté par  . Évalué à 0.

          Merci pour ton aide nous avons trouvé la solution
          en changeant le paramètre suivant

          Suppression d'une acl contenant forwarded_for delete

          Remplacement du "forwarded_for off" par "forwarded_for on" dans une acl depuis le site edf.com est accessible.

          Je pense que il est fort probable que l'un tech a fait une mauvaise manipe sur le fichier.

          • [^] # Re: acl ?

            Posté par  . Évalué à 2.

            Remplacement du "forwarded_for off" par "forwarded_for on" dans une acl depuis le site edf.com est accessible.

            Je pense que il est fort probable que l'un tech a fait une mauvaise manipe sur le fichier.

            t'as plus qu'a prié que cette regle modifiée ne change pas tous pleins d'autres sites.
            d'ailleurs elle fait quoi cette regle ?

  • # erreur 407?

    Posté par  . Évalué à 3.

    y'aurait pas comme un souci d'authentification au niveau de squid?
    je lis ca comme étant un squid qui attends un login/password non fourni par ton navigateur.

    • [^] # Re: erreur 407?

      Posté par  (site web personnel) . Évalué à 1.

      Oui d'ailleurs sur la première ligne, qui fonctionne, il y a USERAD.
      Après je n'ai pas utilisé squidguard depuis longtemps quand il bloque il génère peut-être ce type de log

      • [^] # Re: erreur 407?

        Posté par  . Évalué à 1.

        Concernant l'authentification nous n'avons pas de problèmes.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.