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:
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 NeoX . É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:8080tu 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 $IPtu 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 ACCEPTtu 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 Gauthier (Mastodon) . Évalué à 1.
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 Gauthier (Mastodon) . Évalué à 1.
iptables -t nat -A PREROUTING -i vmbr1 -s ! 192.168.1.250 -p tcp --dport 80 -j DNAT --to 192.168.1.250:8080Alors 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 NeoX . Évalué à 2.
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 Gauthier (Mastodon) . Évalué à 2.
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 NeoX . Évalué à 3.
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 Gauthier (Mastodon) . Évalué à 1.
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 Gauthier (Mastodon) . Évalué à 1.
#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 Gauthier (Mastodon) . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.