Plus d'accès au serveur web après activation openvpn

Support Debian
, ,
Tags: #<Tag:0x00007fc9e207a220> #<Tag:0x00007fc9e207a0e0> #<Tag:0x00007fc9e2079f28>
#22

C’est la configuration classique d’openvpn lorsqu’il se positionne comme route par défaut. D’abord il crée une route spécifique pour l’adresse du serveur distant (213.232.87.63) calquée sur la route par défaut actuelle sinon les paquets transportant le VPN seraient routés dans le VPN. Ensuite, au lieu de remplacer la route par défaut existante, il crée deux nouvelles routes pour router une moitié de l’espace d’adressage total chacune (0.0.0.0/1 et 128.0.0.0/1) via le VPN. Ces destinations étant plus spécifiques que la route par défaut, elles sont systématiquement préférées et la route par défaut n’est plus utilisée tant que ces deux routes existent quelles que soient les éventuelles métriques (priorités) associées aux routes qui ne s’appliquent qu’en cas de conflit entre des routes couvrant la même taille de destination.

Pour ta problématique, il faut définir précisément quel trafic sortant doit être routé via le VPN ou via le routeur du LAN. Classiquement, il y a deux approches possibles :

  • soit on définit ce qui doit être routé via le VPN et on route tout le reste via le routeur du LAN
  • soit on définit ce qui doit être routé via le routeur du LAN et on route tout le reste via le VPN

Dans les deux cas il faut tout prendre en compte, y compris le trafic « utilitaire » comme DNS.

Le choix se fait généralement selon laquelle des deux catégories de trafic est la plus simple à caractériser.
Exemples de stratégies possibles :

  1. on route via le routeur du LAN tous les paquets ayant tels ports source (correspondant à des services accessibles depuis l’extérieur via le routeur du LAN) et le reste via le VPN
  2. plus générique : on route via le routeur du LAN tous les paquets appartenant ou liés (attention au mode actif FTP) à une connexion entrante reçue via le routeur du LAN et le reste via le VPN
  3. plus simple : on route via le routeur du LAN tous les paquets ayant l’adresse source de l’interface LAN (qui sont par défaut des paquets de réponse à une connexion entrante à destination de cette adresse) et le reste via le VPN
  4. on route via le VPN les paquets ayant tels ports source et/ou destination (correspondant au type de trafic qu’on veut faire passer par le VPN) et le reste via le routeur du LAN.

Chacune de ces stratégies a des avantages et des inconvénients :

  1. a besoin d’iptables et ne prend pas en compte les messages d’erreur ICMP liés aux connexions entrantes
  2. a besoin d’iptables et peut mal fonctionner avec les protocoles complexes comme FTP en mode actif qui impliquent des connexions sortantes
  3. n’a pas besoin d’iptables mais ne fonctionne pas avec les services UDP qui ne fixent pas l’adresse source des paquets émis (car c’est l’adresse de l’interface de sortie avant reroutage, donc du VPN, qui est utilisée par défaut)
  4. a besoin d’iptables et il faut être sûr de ne rien oublier sinon ce sera routé via le routeur du LAN

Si la stratégie choisie a besoin de règles iptables pour marquer les paquets, il faut faire attention à l’intégration avec ufw ou autre pare-feu.

A toi maintenant de définir les types de trafic.

#23

Bonjour désolé pour le délai de réponse
Hmm la solution 3 semble la mieux

plus simple : on route via le routeur du LAN tous les paquets ayant l’adresse source de l’interface LAN (qui sont par défaut des paquets de réponses à une connexion entrante à destination de cette adresse) et le reste via le VPN ça me parais entre le plus simple.

Pour information le ftpes vsftpd a était paramétrer pour fonctionner de façon passiv (passiv port) actif avec la plage 12600-12650 en tcp

Globalement, le seul trafique qui dois passer sûr via le lan, ce sont les services web + FTP globalement, je pense que la solution 3 est la bonne

Après la solution 1 est aussi valable mais en sois le système fonctionne que sur du tcp donc la solution 3 et plus simple je pense

#24

Solution 3 :

ip rule add to 192.168.42.0/24 priority 100 table main
ip rule add from 192.168.42.0/24 priority 200 table 200
ip route add default via 192.168.42.1 dev ens18 table 200

La troisième commande initialise une table de routage pour tout envoyer à la box.
La seconde commande crée une règle qui applique cette table de routage à tous les paquets émis avec une adresse source du LAN (au cas où l’adresse d’ens18 serait variable)
La première commande crée une règle prioritaire sur la précédente qui applique la table de routage normale (main) aux paquets émis avec une adresse de destination du LAN pour qu’ils ne soit pas envoyés à la box.

A tester manuellement puis à exécuter à chaque démarrage. Si l’interface ens18 est configurée dans /etc/network/interfaces, une méthode possible est d’utiliser l’option up.

#25

Hello merci pour l’information sa fonctionne nickel

Donc dans le fichier /etc/network/interfaces j’ai add ses lignes la

a la suite pour ens18

up ip rule add to 192.168.42.0/24 priority 100 table main
up ip rule add from 192.168.42.0/24 priority 200 table 200
up ip route add default via 192.168.42.1 dev ens18 table 200

Pour info, l’interface est gravée en dur et en IP fixe donc ens18 ne devrais pas bouger la seule interface qui bouge parfois, c’est le vpn parfois, c’est tun0 et parfois, c’est tun1

Merci à vous pour l’aide en tout cas :slight_smile:

#26

Petit avertissement : si l’interface ens18 est arrêtée et redémarrée avec ifdown+ifup ou le service networking, les commandes "ip rule sortiront en erreur car les règles existent déjà et les commandes suivantes ne seront pas exécutées. A contrario la route est supprimée automatiquement lorsque l’interface est désactivée, et ne sera pas recréée si la commande ip route n’est pas exécutée parce que les commandes précédentes sortent en erreur. Pour l’éviter, on peut soit

  • mettre la commande ip route en premier mais ça reste sale car les deux autres seront en erreur même si ça n’a pas d’impact
  • ajouter «  || true » à la fin des deux commandes pour qu’elles sortent en succès, comme indiqué dans man interfaces
  • ajouter des commandes down pour supprimer les règles lors de l’arrêt de l’interface afin qu’elles puissent être recréées sans erreur
  • déplacer les deux commandes dans la définition de l’interface lo qui n’est normalement pas redémarrée, même lors du redémarrage du service networking
#27

hello donc si je comprend bien sa donnerais sa du coup ?

up ip rule add to 192.168.42.0/24 priority 100 table main || true
up ip rule add from 192.168.42.0/24 priority 200 table 200 || true
up ip route add default via 192.168.42.1 dev ens18 table 200 || true

actuellement mon fichier ressemble a cela

# 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 ens18
iface ens18 inet static
        address 192.168.42.21/24
        gateway 192.168.42.1
        # static route
        up ip rule add to 192.168.42.0/24 priority 100 table main
        up ip rule add from 192.168.42.0/24 priority 200 table 200
        up ip route add default via 192.168.42.1 dev ens18 table 200
#28

Oui, c’est ça.

#29

OK modification effectué
merci pour votre aide
tout est fonctionnel
Je passe incident en résolue

Plus d’accès au serveur web après activation Wireguard