Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Linux Autres OS Linux Debian HS: iptables et redirection vers lo

HS: iptables et redirection vers lo

6 réponses
Avatar
Daniel Huhardeaux
Bonjour,

voici le setup:

. un serveur avec des machines virtuelles kvm, reseau 10.0.70.1 pour le
serveur, 10.0.70.[11|12|...|] pour les VM.
. deux réseaux OpenVPN 10.99.3.1 (serveur VPN) et 10.99.3.18 (client VPN)

J'ai paramétré libvirtd+tls de manière à ce qu'il n'écoute que sur
l'adresse 10.0.70.1 Le problème est que libvirt ne démarre pas si cette
adresse n'existe pas et comme c'est lui qui la créée en créant le
network des VM, c'est pas cool ;-)

Ce que je voudrai: libvirtd+tls démarre en écoutant 127.0.0.1 le port
étant 16514 et iptables redirige les requêtes du port 16540 IP 10.0.70.1
vers 127.0.0.1 J'ai donc créé les règles suivantes, sachant que je me
connecte en VPN sur le réseau serveur, forcément ;-), et que celui ci
est parfaitement fonctionnel. Voici donc ces règles:

iptables -t nat -A PREROUTING -p tcp -d 10.0.70.1 --dport 16514 -j DNAT
--to 127.0.0.1
iptables -A INPUT -p tcp --dport 16514 -j ACCEPT

Sachant que mon iptables autorise lo:

iptables -A INPUT -p all -i lo -j ACCEPT
iptables -A FORWARD -p all -i lo -j ACCEPT
iptables -A OUTPUT -p all -o lo -j ACCEPT

les VPN

iptables -A INPUT -p all -i tun+ -j ACCEPT
iptables -A FORWARD -p all -i tun+ -j ACCEPT
iptables -A OUTPUT -p all -o tun+ -j ACCEPT

les VM

iptables -A INPUT -p all -i virbr+ -j ACCEPT
iptables -A FORWARD -p all -i virbr+ -j ACCEPT
iptables -A OUTPUT -p all -o virbr+ -j ACCEPT

Je vois bien que des packets passent par ma règle de PREROUTING mais je
ne reçois aucune réponse, rien dans la règle INPUT.

Une idée de ce qui me manque? Merci pour toute idée

--
Daniel

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/4D288A7D.2020706@tootai.net
Signaler un problème avec ce contenu

6 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Daniel Huhardeaux
Le 08/01/2011 17:02, Daniel Huhardeaux a écrit :
[...]

Ce que je voudrai: libvirtd+tls démarre en écoutant 127.0.0.1 le port
étant 16514 et iptables redirige les requêtes du port 16540 IP
10.0.70.1 vers 127.0.0.1


[...]

Erreur typo: il s'agit bien du port 16514 et non 16540. Désolé :-(

--
Daniel

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Bernard Schoenacker
Le Sat, 08 Jan 2011 17:02:05 +0100,
Daniel Huhardeaux a écrit :

Bonjour,

voici le setup:

. un serveur avec des machines virtuelles kvm, reseau 10.0.70.1 pour
le serveur, 10.0.70.[11|12|...|] pour les VM.
. deux réseaux OpenVPN 10.99.3.1 (serveur VPN) et 10.99.3.18 (client
VPN)

J'ai paramétré libvirtd+tls de manière à ce qu'il n' écoute que sur
l'adresse 10.0.70.1 Le problème est que libvirt ne démarre pas si
cette adresse n'existe pas et comme c'est lui qui la créée en c réant
le network des VM, c'est pas cool ;-)

Ce que je voudrai: libvirtd+tls démarre en écoutant 127.0.0.1 l e port
étant 16514 et iptables redirige les requêtes du port 16540 IP
10.0.70.1 vers 127.0.0.1 J'ai donc créé les règles suivant es, sachant
que je me connecte en VPN sur le réseau serveur, forcément ;-), et
que celui ci est parfaitement fonctionnel. Voici donc ces règles:

iptables -t nat -A PREROUTING -p tcp -d 10.0.70.1 --dport 16514 -j
DNAT --to 127.0.0.1
iptables -A INPUT -p tcp --dport 16514 -j ACCEPT

Sachant que mon iptables autorise lo:

iptables -A INPUT -p all -i lo -j ACCEPT
iptables -A FORWARD -p all -i lo -j ACCEPT
iptables -A OUTPUT -p all -o lo -j ACCEPT

les VPN

iptables -A INPUT -p all -i tun+ -j ACCEPT
iptables -A FORWARD -p all -i tun+ -j ACCEPT
iptables -A OUTPUT -p all -o tun+ -j ACCEPT

les VM

iptables -A INPUT -p all -i virbr+ -j ACCEPT
iptables -A FORWARD -p all -i virbr+ -j ACCEPT
iptables -A OUTPUT -p all -o virbr+ -j ACCEPT

Je vois bien que des packets passent par ma règle de PREROUTING mais
je ne reçois aucune réponse, rien dans la règle INPUT.

Une idée de ce qui me manque? Merci pour toute idée



bonjour,

serait il possible d'employer privoxy ?

objectif : tout placer sur localhost:8118

doc ubuntuforum :

# Allow privoxy to connect to DansGuardian
iptables -t nat -A OUTPUT -p tcp --dport $HTTPPORT -m owner --uid-owner
$PRIVOXYUSER -j ACCEPT iptables -t nat -A OUTPUT -p tcp --dport 8181 -m
owner --uid-owner $PRIVOXYUSER -j ACCEPT

# Redirect users who access $HTTPPORT to $PRIVOXYPORT
iptables -t nat -A OUTPUT -p tcp --dport $HTTPPORT -j REDIRECT
--to-ports $PRIVOXYPORT

# Keep users from connecting to Squid and bypassing Dansguardian
iptables -t nat -A OUTPUT -p tcp --dport 3128 -j REDIRECT --to-ports
$PRIVOXYPORT

slt
bernard

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Pascal Hambourg
Salut,

Daniel Huhardeaux a écrit :

. un serveur avec des machines virtuelles kvm, reseau 10.0.70.1 pour le
serveur, 10.0.70.[11|12|...|] pour les VM.
. deux réseaux OpenVPN 10.99.3.1 (serveur VPN) et 10.99.3.18 (client VPN)

J'ai paramétré libvirtd+tls de manière à ce qu'il n'écoute que sur
l'adresse 10.0.70.1 Le problème est que libvirt ne démarre pas si cette
adresse n'existe pas et comme c'est lui qui la créée en créant le
network des VM, c'est pas cool ;-)



Tu peux attribuer l'adresse 10.0.70.1/32 à une autre interface qui
existe déjà, par exemple l'interface de loopback lo. Il n'est pas
interdit d'attribuer la même adresse à plusieurs interfaces et plusieurs
adresses à la même interface.

Ce que je voudrai: libvirtd+tls démarre en écoutant 127.0.0.1 le port
étant 16514 et iptables redirige les requêtes du port 16540 IP 10.0.70.1
vers 127.0.0.1 J'ai donc créé les règles suivantes, sachant que je me
connecte en VPN sur le réseau serveur, forcément ;-), et que celui ci
est parfaitement fonctionnel. Voici donc ces règles:

iptables -t nat -A PREROUTING -p tcp -d 10.0.70.1 --dport 16514 -j DNAT
--to 127.0.0.1
iptables -A INPUT -p tcp --dport 16514 -j ACCEPT



Si tu comptes y accéder depuis ailleurs que la machine, ça ne marchera
pas : le noyau écarte les paquets ayant une adresse source ou
destination dans 127.0.0.0/8 reçus depuis ou émis vers l'extérieur
(comprendre par une interface non loopback). La subtilité est que cette
vérification en entrée a lieu lors de la décision de routage, après les
chaînes PREROUTING, donc quand l'adresse de destination a été changée en
127.0.0.1.

Une alternative consiste à utiliser un relais de port TCP (rinetd,
socat, redir, 6tunnel, stone, simpleproxy...).

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
daniel huhardeaux
Bonjour

Le 09/01/2011 14:10, Pascal Hambourg a écrit :
[...]
Tu peux attribuer l'adresse 10.0.70.1/32 à une autre interface qui
existe déjà, par exemple l'interface de loopback lo. Il n'est pas
interdit d'attribuer la même adresse à plusieurs interfaces et plusieurs
adresses à la même interface.




Pas propre, ne me plait pas. Si cette adresse IP répond c'est que le
réseau des VM est up. En tant qu'alias elle répondrait également ce qui
risque dínduire en erreur.

[...]
Une alternative consiste à utiliser un relais de port TCP (rinetd,
socat, redir, 6tunnel, stone, simpleproxy...).




Cette solution est parfaite. J'ai testé avec succès stone, rinetd et
simpleproxy et je retiens rinetd, il est très simple.

Merci.
--
Daniel

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Pascal Hambourg
daniel huhardeaux a écrit :

Le 09/01/2011 14:10, Pascal Hambourg a écrit :
[...]
Tu peux attribuer l'adresse 10.0.70.1/32 à une autre interface qui
existe déjà, par exemple l'interface de loopback lo. Il n'est pas
interdit d'attribuer la même adresse à plusieurs interfaces et plusieurs
adresses à la même interface.



Pas propre, ne me plait pas. Si cette adresse IP répond c'est que le
réseau des VM est up. En tant qu'alias elle répondrait également ce qui
risque d'induire en erreur.



Si je ne m'abuse, le même reproche s'applique aussi à une redirection
faite par iptables car elle fonctionne même si l'adresse n'existe pas, non ?

Une alternative consiste à utiliser un relais de port TCP (rinetd,
socat, redir, 6tunnel, stone, simpleproxy...).



Cette solution est parfaite. J'ai testé avec succès stone, rinetd et
simpleproxy et je retiens rinetd, il est très simple.



A ceci près qu'il faut s'assurer que le relais de port est lancé après
que l'adresse 10.0.70.1 existe, puisqu'il doit écouter dessus.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Daniel Huhardeaux
Le 09/01/2011 19:29, Pascal Hambourg a écrit :
daniel huhardeaux a écrit :

Le 09/01/2011 14:10, Pascal Hambourg a écrit :

[...]
Tu peux attribuer l'adresse 10.0.70.1/32 à une autre interface qui
existe déjà, par exemple l'interface de loopback lo. Il n'est pas
interdit d'attribuer la même adresse à plusieurs interfaces et plusieurs
adresses à la même interface.



Pas propre, ne me plait pas. Si cette adresse IP répond c'est que le
réseau des VM est up. En tant qu'alias elle répondrait également ce qui
risque d'induire en erreur.



Si je ne m'abuse, le même reproche s'applique aussi à une redirection
faite par iptables car elle fonctionne même si l'adresse n'existe pas, non ?




Le problème n'est pas iptables mais le fait que l'adresse IP réponde
(icmp par ex) alors que le réseau ne serait pas configuré.

Cette solution est parfaite. J'ai testé avec succès stone, rinetd et
simpleproxy et je retiens rinetd, il est très simple.



A ceci près qu'il faut s'assurer que le relais de port est lancé après
que l'adresse 10.0.70.1 existe, puisqu'il doit écouter dessus.




Oui, mais ceci est gérable.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/