Forum Linux.debian/ubuntu Openvz et squid3 en proxy transparent

Posté par .
Tags : aucun
0
16
jan.
2010
Bonjour à tous,

Je suis en train de monter un serveur proxmox (debian) avec plusieurs machines virtuelles openvz, tout fonctionne bien sauf le squid lorsque j'active le mode proxy transparent.

Le proxy est sur l'interface vmbr1 avec l'IP 192.168.1.250 en mode bridgé. Les postes de travail sont également dans le réseau 192.168.1.0/24 ($MY_NETWORK).

routeur---[vmbr0]PROXMOX[vmbr1]---192.168.1.0/24

J'ai mis ceci dans mon script firewall du serveur Proxmox qui sert de passerelle par défaut des postes du réseau 192.168.1.0/24:

  • iptables -t nat -A PREROUTING -i vmbr1 -s ! 192.168.1.250 -p tcp --dport 80 -j DNAT --to 192.168.1.250:8080
  • iptables -t nat -A POSTROUTING -o vmbr1 -s $MY_NETWORK -d 192.168.1.250 -j SNAT --to $IP
  • iptables -A FORWARD -s $MY_NETWORK -d 192.168.1.250 -i vmbr1 -o vmbr1 -p tcp --dport 8080 -j ACCEPT

  • Le squid écoute bien sur le port 8080.
    Si dans la conf de squid j'ai la ligne : http_port 8080, j'arrive bien sur le squid mais il me dit qu'il ne comprend pas la requête, c'est normal.
    Par contre si dans la conf du squid je mets : http_port 8080 transparent j'ai un gros kernel panic dès qu'un client fait une requête http et mon proxmox est planté.

    Est que quelqu'un a déjà fait ce genre de manip ? Est-ce que la règle iptables vous semble correcte ?

    Merci.
    • # eclaircicement

      Posté par . Évalué à 2.

      iptables -t nat -A PREROUTING -i vmbr1 -s ! 192.168.1.250 -p tcp --dport 80 -j DNAT --to 192.168.1.250:8080

      tu renvoie ce qui arrive sur vmbr1:80 vers vmbr1:8080 (sauf ce qui vient du serveur lui meme) => OK

      iptables -t nat -A POSTROUTING -o vmbr1 -s $MY_NETWORK -d 192.168.1.250 -j SNAT --to $IP
      tu change ce qui vient de MY_NETWORK (arrive par vmbr1) et qui sort par vmbr1 (???)
      ET qui est à destination de ta machine, par une ip source IP => je ne vois pas bien l'interet

      iptables -A FORWARD -s $MY_NETWORK -d 192.168.1.250 -i vmbr1 -o vmbr1 -p tcp --dport 8080 -j ACCEPT
      tu acceptes le forward entre vmbr1 et vmbr1 => ???


      je penses que tu confond le transfert en prerouting et le forward vers vmbr0

      vire les 2 dernieres lignes, et regarde si ca marche
      attention aussi à ton adressage

      vmbr0 ne doit pas etre sur le meme reseau que vmbr1, et doit te fournir une passerelle par defaut (ton routeur)
      • [^] # Re: eclaircicement

        Posté par . Évalué à 1.

        Merci pour tes éclaircissements.
        Pour les forwards, je ne sais pas trop. Oui les machines de mon réseau sont sur la même interface que le proxy, mais le proxy est une vm sur le firewall, donc les paquets doivent être routé sur le firewall jusqu'à cet VM pour moi.
        Je vais tester sans les 2 forwards pour voir.
        • [^] # Re: eclaircicement

          Posté par . Évalué à 1.

          Même chose (kernel panic) si je ne laisse que:
          iptables -t nat -A PREROUTING -i vmbr1 -s ! 192.168.1.250 -p tcp --dport 80 -j DNAT --to 192.168.1.250:8080
          Alors que si je retire l'option transparent dans la conf de squid3 il me retourne la page suivante dans mon navigateur:

          ERROR
          The requested URL could not be retrieved

          While trying to retrieve the URL: /

          The following error was encountered:

          * Invalid URL

          Some aspect of the requested URL is incorrect. Possible problems:

          * Missing or incorrect access protocol (should be `http://'' or similar)
          * Missing hostname
          * Illegal double-escape in the URL-Path
          * Illegal character in hostname; underscores are not allowed

          Your cache administrator is webmaster.
          Generated Sat, 16 Jan 2010 14:24:50 GMT by localhost (squid/3.0.STABLE8)
        • [^] # Re: eclaircicement

          Posté par . Évalué à 2.

          donc effectivement tu as probablement un probleme de route par defaut

          il ne faut pas que vmbr0 et vmbr1 soit sur le meme reseau,
          ou alors n'utiliser qu'une seule interface

          qui sera le recepteur des demandes sur le port 80 (renvoyé au port 8080)
          sauf pour ce qui vient du proxy en lui meme

          seulement il faut que tes machines clientes sachent qu'elles doivent passer par ce proxy...
          (proxy non transparent)

          pour un proxy transparent
          il faut que ce soit ton firewall qui renvoie le port 80 vers le proxy:8080 (sauf ce qui vient du proxy)
          • [^] # Re: eclaircicement

            Posté par . Évalué à 2.

            vmbr0 est en 10.0.0.0/24 et vmbr1 et en 192.168.1.0/24 c'est bien 2 cartes distinctes sur mon firewall. La route par défaut des postes est 192.168.1.1 qui est le firewall.
            Le proxy ainsi que les postes de travails sont sur le réseau 192.168.1.0/24.

            Je ne vois pas en quoi il peut être gênant d'avoir le proxy et les postes de travail sur le même réseau.

            La règle iptables de PREROUTING fonctionne bien car j'arrive bien sur squid lorsque je fais un telnet www.google.fr 80. Je crois que si je ne trouve pas je vais faire tourner un petit serveur web indiquant de configurer le proxy comme il faut, ou demander à squid de faire une page d'erreur plus parlante.

            Le plus gênant dans cette histoire, c'est le kernel panic. Je pers 5 minutes à chaque fois que je fais un test.
            • [^] # Re: eclaircicement

              Posté par . Évalué à 3.

              si la route par defaut de tes machines est 192.168.1.1

              il faut :
              - soit que ton proxy soit sur 192.168.1.1 (à la place du parefeu)
              - soit que le parefeu renvoie ce qui rentre sur 192.168.1.1:80 vers 192.168.1.250:8080 (sauf ce qui vient de la machine 250

              - et que la route par defaut du proxy soit 192.168.1.1 (si tu veux que ca repasse dans le parefeu) soit en 10.0.0.0/24 pour aller chercher le routeur (sans passer par le parefeu)
              • [^] # Re: eclaircicement

                Posté par . Évalué à 1.

                J'ai mis un squid sur un vrai serveur et ça fonctionne sans problème.
                Par contre il doit vraiment y avoir un bug avec OpenVZ et squid3 en mode transparent, car même en virant toutes les règles iptables, le simple fait de faire écouter squid3 sur un port avec la directive transparent, fait planter lamentablement le serveur à la moindre tentative de connexion sur ce port.
                Je vais essayer de changer le vz.conf pour autoriser des commandes iptables supplémentaire dans les VE.
                • [^] # Re: eclaircicement

                  Posté par . Évalué à 1.

                  C'est beaucoup mieux. En modifiant le fichier vz.conf et en remplacant la ligne:
                  #IPTABLES='ipt_REJECT ipt_tos ipt_limit ipt_multiport iptable_filter iptable_mangle ipt_TCPMSS ipt_tcpmss ipt_ttl ipt_length'
                  par IPTABLES='ipt_REJECT ipt_tos ipt_limit ipt_multiport iptable_filter iptable_mangle ipt_TCPMSS ipt_tcpmss ipt_ttl ipt_length ip_conntrack ip_conntrack_ftp ip_conntrack_irc ipt_LOG ipt_conntrack ipt_helper ipt_state iptable_nat ip_nat_ftp ip_nat_irc ipt_TOS'
                  Je n'ai plus de Kernel panic. Donc squid en appelant une directive iptables ( ip_conntrack) non supportée par la VE faisait planté le serveur.

                  Par contre le squid3 ne fonctionne pas encore correctement. J'ai toujours le message "invalid url"
                  Si d'un poste je fais:
                  telnet www.google.fr 80
                  GET / HTTP1.0
                  ça marche pas.

                  telnet www.google.fr 80
                  GET http://www.google.fr HTTP1.0
                  ça marche.

                  Une idée ?
                  • [^] # Re: eclaircicement

                    Posté par . Évalué à 1.

                    C'est bon ça fonctionne. Je viens de perdre 1/2 heure car ma règle iptables m'envoyait sur le port 3128 sur lequel je n'avais pas mis la directive transparent.

    Suivre le flux des commentaires

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