VPN et routage

Support Debian
#1

Bonjour,

je sais qu’il y a plein de sujet sur ce probleme mais butant dessus depuis 3 jours, malgré les heures passé sur les différentes discussions sur ce forum, je viens quémander de l’aide.

j’ai un serveur OPENVPN / WIREGUARD qui a deux pattes.
ce serveur est sur Internet.

Eth0 : autorise le ssh et l’openvpn
eth1 : est ma sortie internet de mon vpn. je voudrais que les clients VPN n’est pas de restriction sur internet.

la partie VPN monte parfaitement bien, c’est la partie routage proprement parler qui me pose problème. je suis sur que c’est juste un petit details, mais je ne vois pas où je me plante.

voici les lignes l’iptable :

iptables -F 
iptables -X 

iptables -F -t nat 
iptables -X -t nat

iptables -P INPUT DROP 
iptables -P OUTPUT DROP
iptables -P FORWARD DROP 

iptables -A INPUT -i eth0 -p tcp -m tcp --dport 1194 -j ACCEPT 
iptables -A OUTPUT -o eth0 -p tcp -m tcp --sport 1194 -j ACCEPT

iptables -A INPUT -i eth0 -p tcp -m tcp --sport 22 -j ACCEPT 
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT 
iptables -A OUTPUT -o eth0 -p tcp -m tcp --sport 22 -j ACCEPT 
iptables -A OUTPUT -o eth0 -p tcp -m tcp --dport 22 -j ACCEPT 

iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

je vous remercie d’avance de votre aide.

Je me penche sur nftable pour faire la même chose, mais c’est encore un autre sujet… lol

#2

Peux-tu préciser ? A quoi chacune de ces interfaces est-elle reliée ?
Quelle est le contenu de la table de routage ?

ip rule
ip addr

Quel problème exactement ?

Cette règle est une faille de sécurité. Elle permet à n’importe qui de se connecter à n’importe quel port TCP du serveur du moment qu’on utilise le port source 22. Pour autoriser le trafic retour de connexions sortantes, il faut utiliser le suivi de connexion (conntrack), et pas (seulement) le port source.

Je ne vois aucune règle acceptant le trafic dans la chaîne FORWARD.

#3

eth0 est une interface sur laquelle je fais pointer mon tunnel VPN et j’autorise aussi les accès SSH via cette interface uniquement. ( correspond à une interface LAN)
eth1 est l’interface qui me permettra de sortir du serveur vers le WEB. (correspond à une interface WAN)

pour le moment je bosse sur une VM pour maitriser ce sujet de routage qui me fait vraiment defaut ( en connaissance aussi)
IP route :

bzhandroid@SRV2021-DEB:~# ip route
default via 192.168.4.1 dev eth0 onlink
10.8.0.0/25 via 10.8.0.2 dev tun0
10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1
192.168.2.0/24 dev eth1 proto kernel scope link src 192.168.2.10  #RSO du  WAN
192.168.4.0/24 dev eth0 proto kernel scope link src 192.168.4.10  # RSO du LAN

bzhandroid@SRV2021-DEB:~# ip rule
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default
bzhandroid@SRV2021-DEB:~# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:0c:29:fa:54:91 brd ff:ff:ff:ff:ff:ff
    inet 192.168.4.10/24 brd 192.168.4.255 scope global ens33
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fefa:5491/64 scope link
       valid_lft forever preferred_lft forever
3: ens34: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:0c:29:fa:54:9b brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.10/24 brd 192.168.2.255 scope global ens34
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fefa:549b/64 scope link
       valid_lft forever preferred_lft forever
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none
    inet 10.8.0.1 peer 10.8.0.2/32 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::51ed:6e04:52dc:6661/64 scope link stable-privacy
       valid_lft forever preferred_lft forever

je voudrais que mes paquets qui arrivent du TUN0 aille vers eth1.

merci pr l’info pour le port 22, je vais aussi me pencher sur cette faille ensuite .

#4

Pas sûr qu’utiliser une VM soit le plus simple.

Que signifie « RSO » ?

Alors pourquoi la route par défaut est sur eth0 ?

Et comment se fait-il que les noms des interfaces dans la sortie de ip addr ne correspondent pas avec le reste de la description ?

Non, ce n’est pas ce que tu veux, crois-moi.

#5

RSO signifie réseau, j’ai mis le commentaire pr expliquer.

dans ip addr je n’ai pas remplacer ens33 par eth0 et ens34 par eth1 . pour la route par defaut, je n’ai rien rentré,

je devrai donc supprimer la route par defaut,
et mettre la route par defaut de mon interface.
si je me plante pas, je peux le faire dans mon fichier d’interface dans la partie de ma carte eth1

iface eth1 inet static
address 192.168.2.10/24
gateway  192.168.2.2
    post-up ip route del default
    post-up ip route add default via  192.168.2.2 dev eth1

pourquoi tu dis « Non, ce n’est pas ce que tu veux ,crois moi »?
j’aimerai utilisé le serveur comme point de sortie de mes clients VPN vers le WEB.

Je dois peut etre faire fausse route, , serait il possible davoir des conseils alors.
autant la partie systeme me pose pas de soucis, mais la partie reseau/ routage est pour moi assez neuf. quand je fais le tour des sites qui en parle, personne à la même méthode… et donc je pioche à droite et gauche pr faire avancer ma solution… ( ce qui n’est pas forcément la bonne méthode).

#6

Pourquoi remplacer les noms des interfaces ? Cela ne fait qu’embrouiller les choses.

En tout cas elle n’est pas arrivé là toute seule, elle vient bien de quelque part. Comment l’interface eth0 est-elle configurée ?

Euh, non, tu devrais plutôt configurer la route par défaut uniquement là où elle doit être, sur eth0. D’après toi avec ta méthode bancale il se passera quoi si eth1 est configurée avant eth0 ?

Parce que c’est le cas. Par exemple tu ne voudrais pas que des paquets à destination du LAN ou du serveur soient envoyés par eth1, n’est-ce pas ?

J’ai bien compris.

#7

desole pr l’embrouillage des nom d’interface. je travaille sur des VM pour m’entrainer et comprendre correctement la mise en place du pare feux et du routage.

l’interface eth0 est configurer dans le fichier /etc/network/interface

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 192.168.4.10/24
gateway 192.168.4.1
allow-hotplug eth1
iface eth1 inet static
address 192.168.2.10/24
gateway 192.168.2.2
    post-up ip route del default
    post-up ip route add default via  192.168.2.2 dev eth1
pre-up iptables-restore < /etc/iptables_backups.save

il faut voir mon schema comme une machine unique qui veut sortir sur le net par un vpn…;
J’aimerai comprendre comment gerer le routage comme pourrait le faire les serveurs vpn chez Northvpn par exemple. mais sur mes serveurs j’ai deux cartes réseaux une pour faire la connection avec le client vpn et l’autre carte pour aller sur le net.

#8

Les excuses m’indiffèrent et je ne vois pas le rapport entre le fait de travailler sur des VM et et le fait de trafiquer les noms des interfaces.

Ah ouais ? Et ça, c’est quoi ?

Commence par configurer correctement tes interfaces, et ça ira mieux.

Pourquoi deux interfaces séparées ? Le client ne vient pas d’internet ?

#9

est ce nécessaire de mal me parler.

tu as l’air d’avoir des connaissances, et la seule chose que j’ai le droit depuis le début de la discussion ce n’est pas de l’aide …

au lieu de dire " commence par configurer correctement tes interfaces, et ca ira mieux, tu aurais pu m’expliquer en quoi mes interfaces sont mal configurer…

#10

Quand on me mène en bateau, ça a tendance à m’agacer. Sorties de commandes trafiquées, affirmations mensongères… ça commence à faire beaucoup.

Je t’ai montré la ligne qui ne va pas, ça ne te suffit pas pour comprendre ?

Tu as configuré des routes par défaut (option gateway) sur deux interfaces, alors que par définition, un truc « par défaut », il ne doit y en avoir qu’un. Arrive ce qui doit arriver (une chance sur deux) : la route par défaut effective n’est pas sur la bonne interface. Et toi, plutôt que de de retirer l’option gateway en trop, tu as préféré ajouter des commandes pour annuler l’effet de cette option et obtenir l’effet de l’autre option gateway qui n’a pas été prise en compte. Voilà ce qui ne va pas.

#11

Je vous prie de m’excuser de mettre mon grain de sel mais sachez que l’image que vous donnez de la communauté linuxienne en générale et de Debian en particulier est déplorable

1 J'aime
#12

Voici un schema pour que cela soit plus parlant. avec correction
image

j’ai donc un PC qui se connecte sur une interface de mon serveur , qui se trouve sur le net avec un client VPN. le client sortira sur le net à partir d’une autre interface du serveur vers le net.

#13

Habituellement c’est des clients sur le web qui utilise un VPN pour atteindre une/des ressource(s) dans une DMZ ou pour rejoindre un LAN.
Si tu souhaite filtrer qui a droit de sortir sur le net depuis ton réseau local, il y a clairement plus simple à faire.

  • EDIT - C’est déjà plus claire avec ton schéma modifié, mais je ne comprends pas pourquoi tu cherches à faire rentrer des postes via un VPN sur un serveur pour leur permettre par la suite de ressortir vers le net, tu cherche à appliquer du filtrage sur ces postes ?
    quid lorsque le VPN ne sera pas monté … oO
#14

Une chose n’est pas claire pour moi : en regardant ton schéma, j’ai l’impression que le client, le tunnel et l’interface eth0 du serveur ne sont pas sur internet mais sur un réseau distinct. Qui a raison : le schéma ou le texte en dessous ?

#15

Bonjour,

2 petites questions :
Les clients et le serveur OpenVPN sont sur le même réseau ? Si oui, pourquoi tu mets en place un vpn sur un réseau privé ?
Ton but, si je comprends bien, c’est que le serveur assure le rôle de proxy ?

#16

le serveur est loué chez un provider avec deux cartes réseau. mon client ne sera pas dans le même réseau.

#17

ils ne sont pas sur le meme réseau.

on peut effectivement voir le role du serveur comme un proxy.

#18

Concrètement, ils sont sur quel genre de réseau si ce n’est pas internet, et comment font-ils pour se connecter au serveur qui est sur internet ?

#19

je n’ai pas d’utilité immédiate, mais je voulais juste maitriser le montage de ce systeme. Dans mon idée, je veux que mes clients sortent de chez eux ou puissent se connecter sur un wifi public (par exemple) avec leur client vpn qui viendrait se connecter sur ce serveur. et aller tranquillement sur le net.

je n’ai rien de bien compliqué dans mon montage. juste il faut que j’arrive a router le flux de mes clients vpn vers l’interface eth1 et avoir internet.

#20

mes clients peuvent etre sur des réseaux privés ou publiques. et le serveur sur internet.
mon client VPN a l’adresse IP du serveur VPN dans son fichier de conf.