IP failover - parefeu sur CT openVZ

Bonjour,

Tout est presque dans le titre.

J’ai une machine sur OVH sur laquelle j’ai installé proxmox et plusieurs CT en openVZ.
Le routage pour les machine à partir de l’IP du serveur fonctionne impeccable.

J’ai pris une IP Failover pour diffuser mon site web, j’y ai installé munin et monit, configuré les dns et pour afficher le site web tout marche bien.
Parcontre, lorsque j’entre l’ip-failover:1337 pour accéder à monit qui est sur mon CT, ça ne fonctionne pas.

Ma question est la suivante :

Comment se fait-il que je réussisse à me connecter sur mon site web via l’ip_failover et pas sur monit ?
Comment ouvrir le port du CT puisqu’aparamment celui-ci est fermé ?
Ai-je besoin de mettre un parefeu sur un CT ? J’ai déjà essayé mais à chaque coup je me fais éjecter…

Merci

set httpd port 8080 and use address localhost
allow localhost

J’ai ca dans ma config monit.

Et si tu as "address " et que tu remplaces par "address " ?

Perso je ne l’utilise qu’avec localhost (address localhost) depuis localhost (allow localhost).

Hello !

Ta solution ne fonctionne pas…

En fait, mon IP_failover et routée sur l’IP_serveur
Je ne sais par quel miracle je réussis à me connecter sur le port 80 sur mon site et pas ailleurs… Un vrai mystère !

[quote=“Colt22”]Hello !

Ta solution ne fonctionne pas…

En fait, mon IP_failover et routée sur l’IP_serveur
Je ne sais par quel miracle je réussis à me connecter sur le port 80 sur mon site et pas ailleurs… Un vrai mystère ![/quote]

Autant appellé un chat un chat.

Ton IP failover n’est simplement qu’une IP supplémentaire.

Pour le restant il te faut savoir exactement ce que tu compte obtenir comme rendu avec ton IP supp et ton IP.

Bin j’ai paramétré mon ip failover ainsi que les dns pour que ça tombe directement sur le CT.
Donc le site web fonctionne et le ssh aussi sur cette ip là.

Parcontre je ne comprends pas pourquoi le restant des ports est bloqué alors que pour mon IP failover je n’ai strictement rien programmé, pas même le port 80…

Sans réponse clair de ta part pour savoir ce que tu cherche à faire je te file un peu de lecture surl e principe de failover : en.wikipedia.org/wiki/Failover

Et un article traitant de la haute disponibilité : fr.wikipedia.org/wiki/Haute_disponibilit%C3%A9

Donc la question est-tu sûr de parler d’IP failover ou d’IP supplémentaire, cherche tu a mettre ne place de la redondance ou un deuxième accès à toon serveur pour des services différents ?

Alors pour répondre à ta question…

J’en sais fichtre rien… J’ai acheté chez ovh une ip failover (c’est comme ça qu’ils l’ont baptisée et je n’ai pas vu mentionné chez OVH le terme d’IP supplémentaire pour le serveur ou alors va falloir que j’ouvre les yeux plus grands), mais pour moi c’est une IP supplémentaire et je l’utilise comme telle… Alors j’ai bien compris l’histoire de la redondance que si un serveur plante ça bascule sur l’autre, mais je n’ai pas 2 serveurs physiques, il s’agit d’un serveur normal avec proxmox dessus, et ou l’ip est dirigée vers une machine virtuelle… Je ne pense pas pouvoir mieux expliquer…

Cette IP est donc routée sur mon serveur physique mais sur une machine virtuelle en openvz. J’ai configuré les dns pour m’en servir comme si j’avais pris un dédié chez ovh, mais ce don je suis sur, c’est que si mon serveur plante, évidemment la machine virtuelle s’arrêtera.
La VM est configurée comme suit :
IP en venet 91.35.xx.xx
Host truc.monbidule.com

et les dns de mon domaine pointent sur le host de ma vm du style :
truc.monbidule.com ==> 91.35.xx.xx (en type A)
www.monbidule.com ==> truc.monbidule.com (en CNAME)

Donc, mon IP supplémentaire (dont l’intitulé est IP failover) passe par mon serveur physique pour se retrouver en directe sur ma machine virtuelle qui a donc cette ip sur le venet0.

Je ne sais par quelle bizarerie les ports http et ssh sont ouverts, mais lorsque j’essaye d’atteindre les autres ports (ftp ou autre, bin ça bloque)…
Et c’est exactement ça que je ne comprends pas…

Si je tape l’adresse : www.monbidule.com , bin je vois mon site web.
En revanche, si je passe par le FTP, je suis à la ramasse…

Je ne sais pas comment configurer un parefeu sur une vm, j’ai déjà essayé et je me fais éjecter, alors je voudrais comprendre comment ça marche et ce que je peux faire pour ouvrir certains ports…

Tu peu nous montrer le retour d’un dig sur ta zone DNS

dig -t any ton_domain.tld @8.8.8.8

Tu as un iptable d’installer ? si oui les régles serait un plus ?

Ton fichier d’interfaces et la manière de comment as-tu monter ton Ip supplémentaires serait un plus aussi.

Je te rassure OVH font une bonne blague en parlant d’IP failover :whistle:

Ok alors on va commencer par les paramètres du serveur principal :

Ce que le dig a donné :

[code]; <<>> DiG 9.7.3 <<>> -t any www.monsite.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64069
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.monsite.com. IN ANY

;; ANSWER SECTION:
www.monsite.com. 5 IN CNAME host.monsite.com.

;; Query time: 239 msec
;; SERVER: 192.168.117.2#53(192.168.117.2) ==> Trés bizarre j’ai jamais configuré cette IP la…
;; WHEN: Sat Dec 8 08:47:07 2012
;; MSG SIZE rcvd: 51[/code]

Le firewall :

[code]#! /bin/sh

BEGIN INIT INFO

Provides: firewall

Required-Start: $local_fs $remote_fs

Required-Stop: $local_fs $remote_fs

Should-Start: $network $syslog

Should-Stop: $network $syslog

Default-Start: 2 3 4 5

Default-Stop: 0 1 6

Short-Description: Start/stop firewall

Description: Start/stop firewall, a script to set/unset your custom firewall rules

END INIT INFO

IPT=/sbin/iptables

Function that set the firewall rules

set_rules()
{
# On réinitialise le firewall
flush_rules
# On autorise les connexions dont l’état est RELATED ou ESTABLISHED
$IPT -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
# On autorise le serveur à répondre aux requêtes ICMP (ping)
$IPT -A INPUT -i eth0 -p icmp -j ACCEPT
# !! ACCES SSH !! NE PAS COMMENTER CETTE LIGNE !!
$IPT -A INPUT -i eth0 -p tcp --dport xxxx -j ACCEPT
# INTERFACE GRAPHIQUE/WEB de PROXMOX
$IPT -A INPUT -i eth0 -p tcp --dport xxxx -j ACCEPT

# NAT Vz
$IPT -t nat -A POSTROUTING -s 10.0.0.0/24 -o vmbr0 -j SNAT --to ip_serveur

# NAT SQL
$IPT -t nat -A PREROUTING -i vmbr0 -p tcp --dport xxxx -j DNAT --to IP_VM2:22
$IPT -t nat -A PREROUTING -i vmbr0 -p tcp --dport xxxx -j DNAT --to IP_VM2:80
$IPT -t nat -A PREROUTING -i vmbr0 -p tcp --dport xxxx -j DNAT --to IP_VM2:443

#Base de donnée
$IPT -t nat -A PREROUTING -i vmbr0 -p tcp --dport xxxx -j DNAT --to IP_VM2:3306

#NAT Mail
#SSH
	$IPT -t nat -A PREROUTING -i vmbr0 -p tcp --dport xxxx -j DNAT --to IP_VM3:22
	
#WEB
$IPT -t nat -A PREROUTING -i vmbr0 -p tcp --dport xxxx -j DNAT --to IP_VM3:80
	$IPT -t nat -A PREROUTING -i vmbr0 -p tcp --dport xxxx -j DNAT --to IP_VM3:443

#Courrier
$IPT -t nat -A PREROUTING -i vmbr0 -p tcp --dport xxxx -j DNAT --to IP_VM3:25
	$IPT -t nat -A PREROUTING -i vmbr0 -p tcp --dport xxxx -j DNAT --to IP_VM3:110
	$IPT -t nat -A PREROUTING -i vmbr0 -p tcp --dport xxxx -j DNAT --to IP_VM3:465
	$IPT -t nat -A PREROUTING -i vmbr0 -p tcp --dport xxxx -j DNAT --to IP_VM3:993

# On "drop" tout le reste du traffic
$IPT -A INPUT -i eth0 -j DROP
return 0

}

Function that set the firewall rules

flush_rules()
{
$IPT -F INPUT
$IPT -F FORWARD
$IPT -F OUTPUT
return 0
}
command="$1"
case “$command” in
start|force-start|restart|force-restart|reload|force-reload)
flush_rules
set_rules
;;
stop)
flush_rules
;;
status)
$IPT -L
;;
*)
esac
[/code]

et enfin le fichier interfaces :

[code]# This file describes the network interfaces available on your system

and how to activate them. For more information, see interfaces(5).

The loopback network interface

auto lo
iface lo inet loopback

for Routing

auto vmbr1
iface vmbr1 inet manual
post-up /etc/pve/kvm-networking.sh
bridge_ports dummy0
bridge_stp off
bridge_fd 0

vmbr0: Bridging. Make sure to use only MAC adresses that were assigned to you.

auto vmbr0
iface vmbr0 inet static
address IP_serveur
netmask 255.255.255.0
network xxx.xxx.xxx.0
broadcast xxx.xxx.xxx.255
gateway xxx.xxx.xxx.254
bridge_ports eth0
bridge_stp off
bridge_fd 0
[/code]

Pour se qui est de l’install de l’adresse ip supplémentaire je n’ai rien configuré dans ce serveur, j’ai juste installé l’ip dans le container, c’est tout. J’ai fait excatement comme je t’ai déjà expliqué.

Ensuite, sur ma VM1, le ifconfig :

[code]lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:4411 errors:0 dropped:0 overruns:0 frame:0
TX packets:4411 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1513253 (1.4 MiB) TX bytes:1513253 (1.4 MiB)

venet0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:127.0.0.2 P-t-P:127.0.0.2 Bcast:0.0.0.0 Mask:255.255.255.255
UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1
RX packets:24517 errors:0 dropped:0 overruns:0 frame:0
TX packets:22751 errors:0 dropped:47 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:14614223 (13.9 MiB) TX bytes:3621244 (3.4 MiB)

venet0:0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:IP_supplémentaire P-t-P:IP_supplémentaire Bcast:0.0.0.0 Mask:255.255.255.255
UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1
[/code]

Pour le moment, pas de firewall dessus car dès que j’en mets un ça m’éjecte…

Le interfaces de la VM1 :

[code]# This configuration file is auto-generated.

WARNING: Do not edit this file, your changes will be lost.

Please create/edit /etc/network/interfaces.head and

/etc/network/interfaces.tail instead, their contents will be

inserted at the beginning and at the end of this file, respectively.

NOTE: it is NOT guaranteed that the contents of /etc/network/interfaces.tail

will be at the very end of this file.

Auto generated lo interface

auto lo
iface lo inet loopback

Auto generated venet0 interface

auto venet0
iface venet0 inet manual
up ifconfig venet0 up
up ifconfig venet0 127.0.0.2
up route add default dev venet0
down route del default dev venet0
down ifconfig venet0 down

iface venet0 inet6 manual
up route -A inet6 add default dev venet0
down route -A inet6 del default dev venet0

auto venet0:0
iface venet0:0 inet static
address IP_supplémentaire
netmask 255.255.255.255
[/code]

Pour cette machine, je n’ai pas et ne veux pas faire de bridge, il parait qu’au niveau sécurité c’est de la daube, et puis tout es lié dessus, le serveur sql et le serveur mail…
Alors biensur, je peux donner via le nat une ip réseau supplémentaire et ainsi accéder aux ports que je désire, mais ce n’est pas le but de la manoeuvre.
Ce que je veux, c’est, en tapant IP_supplémentaire:port que ça me dirige directement sur la machine qui a cette ip sur le port demandé !

Valaaa, je crois que je ne peux pas t’en dire plus…

Et vu la gueule des règles iptables, c'est un connaisseur qui s'exprime... (De toute façon venet0 est une interface de type routé point à point, on ne peut pas la ponter)

L’interface eth0 est pontée dans vmbr0, donc aucune chance que les règles basées sur eth0 déclenchent. En clair : zéro filtrage.

Quant aux règles DNAT, elles ne prennent pas en compte l’adresse IP destination, ce qui est pourtant indispensable pour ne pas faire n’importe quoi quand on a plusieurs adresses. Ici, elles s’appliquent à toutes les connexions reçues par l’hôte ou émises par les VM pontées sur vmbr0, quelle que soit l’adresse destination (principale, supplémentaire, extérieure). Est-ce ce qui est souhaité ?

Il manque aussi des informations qui pourraient être utiles.

  • Tables de routage de l’hôte et de la VM
  • ifconfig de l’hôte
  • Description concrète de “ça ne marche pas”

PS : Proxmox/openvz fait vraiement des trucs dégueulasses avec le réseau. Affecter une adresse dans 127.0.0.0/8 à une interface non loopback, c’est du grand n’importe quoi et je voudrais bien savoir à quoi ça sert.

Mais lol !

Mon cher Pascal, je te trouve vraiment dur avec moi ! :smiley:
Chuis pas un expert en routage, et justement, j’essaye de comprendre ce que je fais… J’y pige pas grand chose parce que je n’ai jamais fait de routage et je recherche des infos à droite et à gauche pour monter ce foutu serveur. C’est très intéressant quand on a les bonnes explications…

[quote]
L’interface eth0 est pontée dans vmbr0, donc aucune chance que les règles basées sur eth0 déclenchent. En clair : zéro filtrage.[/quote]

Ce que tu veux me dire en claire, c’est que j’aurais rien écrit dans mes règles, ça marcherait tout autant ???

Alors la table de routage de la VM bin ya rien et je ne sais pas faire les route, donc si quelqu’un pouvait m’expliquer, ce serait génial de votre part !

Routage VM donc :

Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 venet0

Routage Hôte :

Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface IP_VM3 0.0.0.0 255.255.255.255 UH 0 0 0 venet0 IP_sup 0.0.0.0 255.255.255.255 UH 0 0 0 venet0 IP_VM2 0.0.0.0 255.255.255.255 UH 0 0 0 venet0 xx.xx.xx.0 0.0.0.0 255.255.255.0 U 0 0 0 vmbr0 0.0.0.0 xx.xx.xx.254 0.0.0.0 UG 0 0 0 vmbr0

[code]dummy0 Link encap:Ethernet HWaddr c6:91:29:ab:12:3b
inet6 addr: fe80::c491:29ff:feab:123b/64 Scope:Link
UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:233 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:15414 (15.0 KiB)

eth0 Link encap:Ethernet HWaddr 00:25:90:7c:68:40
inet6 addr: fe80::225:90ff:fe7c:6840/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:66586 errors:0 dropped:0 overruns:0 frame:0
TX packets:20000 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:58371713 (55.6 MiB) TX bytes:6577615 (6.2 MiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:97 errors:0 dropped:0 overruns:0 frame:0
TX packets:97 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:12939 (12.6 KiB) TX bytes:12939 (12.6 KiB)

venet0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet6 addr: fe80::1/128 Scope:Link
UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1
RX packets:810980 errors:0 dropped:0 overruns:0 frame:0
TX packets:815135 errors:0 dropped:5 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:339183770 (323.4 MiB) TX bytes:341589076 (325.7 MiB)

vmbr0 Link encap:Ethernet HWaddr 00:25:90:7c:68:40
inet addr:IP_du_serveur Bcast:xx.xx.xx.255 Mask:255.255.255.0
inet6 addr: fe80::225:90ff:fe7c:6840/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:56274 errors:0 dropped:0 overruns:0 frame:0
TX packets:19488 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:56825404 (54.1 MiB) TX bytes:6547048 (6.2 MiB)

vmbr1 Link encap:Ethernet HWaddr c6:91:29:ab:12:3b
inet6 addr: fe80::c491:29ff:feab:123b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:468 (468.0 B)[/code]

Sur ma VM1 a laquelle j’ai attribué l’IP supplémentaire, lorsque j’essaye d’afficher monit via le navigateur en tapant IP_supplémentaire:port, le navigateur me revoie : page introuvable

Pose la question à proxmox parce que je suis totalement incapable de te répondre.

Donc en finalité, vu que tu t’y connais très bien en routage, pourrais-je te demander de me faire un script iptables commenté pour quue je puisse comprendre comment on fait la démarche sur le réseau… ça pourrait faire un super tuto ça…

Ce que je veux faire :
Orienter les ports mails sur la VM3, y compris que le port 80 vu que j’ai une interface web pour le courrier
Lier mon serveur sql à toutes les VM, donc VM1 et VM3
Lier mon IP_supplémentaire à la VM1 qui contient mes serveurs web et router les ports 25 et 110 vers la VM3, vu que j’ai mis un relay host vers la vm3 dans postfix.
Et enfin ouvrir le port que je veux sur ma VM1, par exemple le 1337, a qui j’ai attribué mon ip_sup et fait pointer mes dns dessus.
Accessoirement bloquer le ping sur cette ip.

Question, une fois que tout ça est fait :
Dois-je installer un iptables sur la VM1 ou pas nécessairement et pourquoi ?
Dois-je installer fail2ban sur la VM1 ou ce n’est pas nécessaire ?

Voilà… Si t’as besoin d’encore plus d’info, fais signe !

Ah non, les règles DNAT et SNAT de la table nat sont indispensables pour les VM qui ont des adresses privées. Par contre les règles de filtrage ACCEPT/DROP dans la chaîne INPUT de la table filter sont sans effet puisqu’elles spécifie comme interface d’entrée eth0 qui est pontée donc invisible pour la couche IP et iptables (sauf avec les options --physdev-* de la correspondance physdev d’iptables, mais on ne va pas s’embarquer là-dedans, cf. man iptables pour les curieux).

Mais si, il y a juste ce qu’il faut : une route par défaut qui dit de tout envoyer sur l’interface venet0. Pas besoin d’adresse de passerelle car c’est une interface de type point à point.

RAS pour la table de routage de l’hôte. Une route par venet0 pour l’adresse de chaque VM, une route vers le sous-réseau et une route par défaut sur le pont vmbr0 connecté à l’interface physique eth0.

Une petite particularité concernant la sortie d’ifconfig de l’hôte : l’interface venet0 qui sert à communiquer avec les VM n’a pas d’adresse IP. En effet ce n’est pas nécessaire, car le système peut utiliser l’adresse IP d’une autre interface, vmbr0 en l’occurrence, pour communiquer à travers une interface sans adresse IP.

Par contre on voit que le pont vmbr1 ne sert à rien, il n’est lié qu’à dummy0 et il n’y a pas de trafic.
Quant au pont vmbr0, il n’est visiblement lié qu’à eth0. On pourrait donc s’en passer et utiliser directement eth0 à la place.
Je suppose que ces ponts sont liés au fonctionnement possible de proxmox/openvz (que je ne connais pas) en mode ponté, mais ce mode n’est pas utilisé dans ta configuration.

Deux choses.

  1. Par “sur ma VM1”, tu veux dire que tu exécutes un navigateur dans la VM1 ? Ou bien tu exécutes un navigateur sur une autre machine (laquelle ?) pour te connecter à l’adresse de la VM1 ?

  2. J’ai déjà dit à plusieurs reprises, et le répète encore ici, qu’un navigateur est probablement le pire outil pour débugger des problèmes réseau car d’une part il fonctionne à trop haut niveau (HTTP et pas seulement TCP/IP), et d’autre part les messages d’erreurs sont souvent trop vagues pour en déduire quoi que ce soit.

Les outils de base sont :

  • ping ou traceroute <adresse_ou_nom> pour vérifier la connectivité IP (mais peut être filtré)
  • dig, host ou nslookup pour vérifier la résolution DNS
  • tcptraceroute <adresse_ou_nom> pour voir où ça coince en TCP sur le port considéré
  • telnet ou netcat (nc) <adresse_ou_nom> pour se connecter effectivement au port considéré et dialoguer avec lui.

Et bien sûr, avant tout vérifier sur la machine elle-même avec netstat et ps que les services sont bien actifs et les ports bien ouverts en écoute sur les adresses qui vont bien (et pas seulement 127.0.0.1 par exemple).

Pour le reste, on verra plus tard. J’espère juste que les ports utilisés ne font pas partie des ports redirigés par les règles DNAT vers d’autres VM, sinon il va falloir modifier ces règles pour y ajouter “-d <adresse_ip_hôte>” (à faire de toute façon).

J’essaye de me connecter via mon navigateur de mon ordi personnel.
J’ai fait un tcptraceroute , et effectivement le port concerné est fermé… Parcontre le port 80 lui est ouvert… il est ou le bug ? paux-tu m’expliquer ?
J’ai fait un telnet localhost sur la VM concernée et là ça fonctionne… Donc je suppose que je vais devoir rajouter une règle dans le firewaal du serveur principal… mais quelle règle ?

Je constate avec stupéfaction que tu as raison… Je viens de tester en commentant la ligne pour l’interface web, j’ai rebooté le serveur et oui je comprend mieux en fait j’ai 0 filtrage sur mon serveur à la base… Là je flippe…

Je te demande donc quelles règle je dois mettre en place pour ouvrir juste les ports que je veux sur ce serveur stp…
Si tu peux m’en écrire au moins une, je ferais pareil avec les autres…

Et je suppose donc que bloquer le reste du trafic, c’est la même blague, donc si tu pouvais apporter un correctif à mon firewall je t’en serais très reconnaissant !

J’ai essayé mais ça n’a pas fonctionné… me demande pas pourquoi j’en sais rien ! :smiley:

Merci pour tes réponse, ça m’aide à comprendre, parcontre je ne suis pas assez calé en minux pour savoir faire un correctif de tout ça !

Si le traceroute se termine sur l’adresse de la VM, juste après l’adresse de l’hôte, alors le bug est que la VM n’écoute pas sur le port en question.

Non, rien à voir avec le firewall de l’hôte qui est une passoire comme tu l’admets plus bas. “localhost” pointe vers 127.0.0.1, c’est donc une adresse différente de l’adresse publique à laquelle tu tentes de te connecter depuis l’extérieur. Ré-essaie sur la VM avec telnet mais sur son adresse publique, la même que pour le tcptraceroute. Si ça répond fermé comme je le soupçonne, alors le service correspondant n’écoute que sur l’adresse 127.0.0.1, qui n’est accessible que depuis la VM elle-même. C’est à confirmer avec netstat -ntlp comme je le suggérais dans ma réponse précédente. Dans ce cas, il faut configurer le service pour qu’il écoute sur toutes les adresses (0.0.0.0) et pas seulement l’adresse de loopback.

Ça m’arrive assez souvent. Comme je tiens à ma crédibilité, j’évite généralement d’asséner de façon péremptoire des affirmations qui se révèlent ensuite être de grosses conneries.

Il n’y a vraiment pas de quoi flipper. Somme toute, la nécessité du filtrage est très relative. Si on fait tourner un service ouvert à tous on est obligé d’accepter le port correspondant et a contrario si rien n’écoute sur un port il ne sert pas à grand chose de le bloquer. Par contre si tu fais tourner des services mais tu ne veux pas qu’ils soient accessibles, alors effectivement tu as un souci…

Si tu y tiens, il y a un exemple de script iptables dans la section “trucs & astuces” de ce forum, qui vaut ce qu’il vaut. Il faudra le compléter avec des règles dans la chaîne FORWARD pour les communications entre les VM et l’extérieur. Mais on s’en occupera quand le problème initial sera résolu. D’abord, on valide la connectivité. Ensuite, on restreint. Comme ça si quelque chose ne marche pas, on sait d’où ça vient.

Ok alors là effectivement on a avancé…

Là je comprends mieux !
Donc j’ai fait comme tu m’as dit, à savoir que j’ai balancé monit sur le 0.0.0.0, j’ai redémarré le service et… bingo !
Avec telnet sur l’ip publique ça ne fonctionnait pas avant la manip, maintenant oui !
Essai avec tcptraceroute => OPEN !!!

Je sais pas qui tu es dans la vie mais si jamais un jour je te croise, on fêtera ça au champagne ! :smiley:

Donc j’attends la suite avec impatience pour la connectivité avec l’extérieur…

C’est quand même tout de suite plus simple à comprendre quand on a quelqu’un qui explique en détails comment ça fonctionne ! Merci Pascal !

Bon du coup j’édite vu que je comprends un peu mieux comment fonctionne cette satanée machine et ce grâce à tes précieux conseils…
Donc j’ai viré tous les eth0 dans le script ce qui fait que maintenant j’ai bien un filtrage et qui fonctionne je l’ai essayé, et avec le FORWARD je peux enfin avoir accès à mon monit… une vraie galère mais au final ça fonctionne !

Donc merci à tous vous m’avez enlevé une belle épine du pied et tout marche super maintenant !

[quote=“Colt22”]Je te demande donc quelles règle je dois mettre en place pour ouvrir juste les ports que je veux sur ce serveur stp…
Si tu peux m’en écrire au moins une, je ferais pareil avec les autres…[/quote]
Voici un modèle de script qui met en place des règles basiques (pas tester, à corriger et adapter).
[EDIT] Déjà une première correction, la politique par défaut des chaînes des tables autres que filter doivent être à ACCEPT et non DROP. Le filtrage, c’est seulement dans la table filter.

[code]# initialisation des tables et chaines

RAZ table filter

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -F
iptables -X

RAZ table nat

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -F
iptables -t nat -X

RAZ table mangle si active

if grep -q ‘^mangle$’ /proc/net/ip_tables_names
then
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P INPUT ACCEPT
iptables -t mangle -P OUTPUT ACCEPT
iptables -t mangle -P FORWARD ACCEPT
iptables -t mangle -P POSTROUTING ACCEPT
iptables -t mangle -F
iptables -t mangle -X
fi

RAZ table raw si active

if grep -q ‘^raw$’ /proc/net/ip_tables_names
then
iptables -t raw -P PREROUTING ACCEPT
iptables -t raw -P OUTPUT ACCEPT
iptables -t raw -F
iptables -t raw -X
fi

mise en place des regles

autoriser la poursuite des connexions existantes

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

autoriser tout sur l’interface de loopback

iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

nouvelles connexions sortantes autorisees (tout, ajuster si besoin)

iptables -A OUTPUT -m conntrack --ctstate NEW -j ACCEPT

nouvelles connexions entrantes autorisees

iptables -A INPUT -m conntrack --ctstate NEW -p tcp --dport xxx -j ACCEPT

ping (ICMP echo)

iptables -A INPUT -m conntrack --ctstate NEW -p icmp --icmp-type echo -j ACCEPT

nouvelles connexions VM -> internet autorisees (tout, ajuster si besoin)

iptables -A FORWARD -m conntrack --ctstate NEW -i venet0 -o vmbr0 -j ACCEPT

nouvelles connexions internet -> VM autorisees (adresse et port finaux)

iptables -A FORWARD -m conntrack --ctstate NEW -i vmbr0 -o venet0 -d y.y.y.y -p tcp --dport yyy -j ACCEPT

NAT source pour les VM en adressage prive

iptables -t nat -A POSTROUTING -o vmbr0 -s 10.0.0.0/24 -j SNAT --to <ip_hote>

redirections de ports vers les VM en adressage prive (doivent correspondre aux regles FORWARD)

iptables -t nat -A PREROUTING -i vmbr0 -d <ip_hote> -p tcp --dport xxx -j DNAT --to y.y.y.y:yyy[/code]

Pas nécessairement, car l’hôte peut filtrer le trafic entre les VM et internet. En revanche je ne sais pas si le trafic entre deux VM entre et ressort par l’interface venet0 avec routage par l’hôte ou si c’est géré directement par openvz. Dans ce dernier cas, les règles iptables de l’hôte ne protègent pas une VM d’une autre VM qui serait compromise.

Pour utiliser iptables dans les VM, il me semble qu’il faut déclarer les modules du noyau liés à iptables nécessaires aux règles dans openvz (ip_tables, iptable_filter…) et que ces modules soient chargés avant le démarrage d’openvz.

Concernant fail2ban, je n’ai pas d’opinion.

Merci bcp !

Alors j’ai une question :

Le flush rules que j’ai dans mon script ne convient pas ?

flush_rules()
{
    $IPT -F INPUT
    $IPT -F FORWARD
    $IPT -F OUTPUT
    return 0

En fait, d’après ce que je comprends, les chaines vidées sont INPUT, FORWARD et OUTPUT. Est ce que ça veut dire que toutes les politiques sont par défaut (mais pas défaut de quoi ?) : est-ce que à ce stade on n’a plus de règles pour INPUT, FORWARD et OUTPUT ce qui voudrait dire que toutes les connexions entrante et sortantes seraient autorisées ?

Ce script en fait, je dois le remplacer comme suit :

[code]

Initialisation de toutes les tables + vidage

iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -F
iptables -X

Déclaration des politiques + vidage de la table filter

iptables -t filter -P INPUT DROP
iptables -t filter -P OUTPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -F
iptables -t filter -X

Déclaration des politiques + vidage de la table nat

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -F
iptables -t nat -X[/code]

Plusieurs questions :
[ul]
1- Est ce que le script écrit comme celà est juste ?
2- Est-ce que la politique OUTPUT ACCEPT dans la table nat est vraiment nécessaire vu qu’elle se trouve à la base dans toutes les tables ?
3- A ce stade j’ai deux fonctions : flush_rules et set_rules , en fait si ces règles sont justes, je n’ai plus qu’à les coller dans mon script flush_rules et là j’aurais un firewall propre ?
[/ul]

Ça dépend de ce que tu veux que cette fonction fasse.
Là, elle ne fait que vider les chaînes de la table filter (table par défaut, ne pas spécifier d’option -t est équivalent à “-t filter”). Elle ne vide pas les chaînes de la table nat. Au passage, -F sans spécifier de chaîne vide d’un coup toutes les chaînes de la table spécifiée.

Vu l’usage que tu fais de cette fonction dans la commande stop), je suppose que le but est de tout réinitialiser dans l’état d’origine, en supprimant tout filtrage. Dans ce cas il faut aussi remettre les politiques par défaut des chaînes à ACCEPT sinon tout sera bloqué, alors que l’initialisation lors de la mise en place des règles met la politique par défaut des chaînes de la table filter à DROP (sécurité : on bloque tout par défaut).

Si tu mets les politiques par défaut à ACCEPT dans la fonction flush_rules et que tu l’appelles dans ou avant set_rules, alors il faudra mettre la politique de filter à DROP dans set_rules.

Le vidage d’une chaîne et sa politique par défaut sont deux choses indépendantes.
La politique par défaut est la cible qui s’applique lorsque le paquet ne correspond à aucune règle de la chaîne. Evidemment, c’est le cas quand la chaîne est vide. Chaque chaîne de chaque table a sa propre politique par défaut, indépendamment des autres chaînes de la même table ou des chaînes de même nom dans les autres tables (ex: OUTPUT dans filter, mangle, nat et raw sont quatre chaînes indépendantes).

L’absence de règles dans une chaîne ne signifie pas que tout passe ; cela dépend de la politique par défaut de la chaîne : ACCEPT -> tout passe, DROP -> tout est bloqué.

Il y a une incohérence entre les deux premiers paragraphes qui mettent successivement la politique par défaut des chaînes de la table filter à ACCEPT puis DROP (évidemment c’est la dernière qui gagne). Ne pas oublier que la table par défaut est filter si on ne spécifie pas -t.

Je ne comprends pas la question. Quoi qu’il en soit, il faut partir du postulat qu’on ne sait pas dans quel état se trouve iptables, et donc qu’il faut tout initialiser.

Non, car comme expliqué plus haut après tu te retrouverais avec toutes les politiques à DROP après un stop), ce qui n’est probablement pas ce que tu souhaites.

Ok alors entre temps, j’ai fait un test, et c’est vrai que le DROP dans la table filter m’ennuyait !

Donc j’ai viré du firewll tout ce qu’il y avait avec -t filter de manière à avoir une politique ACCEPT sur les chaines INPUT, FORWARD et OUTPUT.

LA démarche est donc :
On place la politique par défaut dans la table filter ACCEPT
ensuite on vide la table, on place les règles, et tout ce qui n’est pas RELATED et ESTABLISHED vire à la fin avec le DROP pour le reste du trafic pour le INPUT…
en gros ça doit être ça…

En tout cas, tout fonctionne donc c’est cool !
Je vais continuer à lire le man iptables car il est vraiment passionnant… parcontre difficile à assimiler pour un novice comme moi !

[quote=“Colt22”]On place la politique par défaut dans la table filter ACCEPT
ensuite on vide la table, on place les règles, et tout ce qui n’est pas RELATED et ESTABLISHED vire à la fin avec le DROP pour le reste du trafic pour le INPUT[/quote]
Une règle DROP en fin de chaîne, c’est moins sûr qu’une politique par défaut à DROP. Lors du vidage de la chaîne celle-ci est grand ouverte pendant quelques instants avant que les règles soient ajoutées. Aussi c’est moins pratique pour ajouter des autorisations à la volée sans tout relancer : les règles sont parcourues dans l’ordre et avec ACCEPT ou DROP c’est la première qui correspond qui gagne. Donc il ne sert à rien d’ajouter les règles en fin de chaîne après la règle DROP car elles seraient ignorées, on doit les insérer avant (-I). On n’a pas ce problème avec une politique par défaut à DROP.

A mon avis la page de manuel d’iptables doit plutôt être limitée au rôle de guide de référence pour retrouver la syntaxe et le sens des différentes options. Pour une compréhension en profondeur, il vaut mieux lire par exemple le tutorial iptables d’Oskar Andreasson dont il existe une traduction en français. Et je peux affirmer que c’est beaucoup plus facile d’écrire des jeux de règles efficaces et correspondant à ses besoins quand on a compris le fonctionnement d’iptables en profondeur !