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

Support Debian
, ,
Tags: #<Tag:0x00007fc9df51d0f0> #<Tag:0x00007fc9df51d000> #<Tag:0x00007fc9df51cee8>
#1

Bonjour,
On a réussi a réglé le problème avec openvpn

pour résumé une fois wireguard activé depuis l’extérieur je n’est plus accès a l’interface web
je pense que tout le traffic entrant sur ens18 ne ressort pas par en18 mais passe dans wireguard (wg0 quand le serveur web renvoie une reponse)

Voir problématique similaire que j’ai eu mais sous openvpn Plus d’accès au serveur web après activation openvpn

je me suis donc dit que j’allais mettre wireguard pour optimisé le débit vpn sa l’optimise sa oui, mais j’ai a nouveau le même problème que précédemment avec openvpn

Sauf que même avec cela (solution précédente dans mon /etc/network/interfaces

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

Ne permets visiblement pas sous wireguard de réglé le problème.
je pense que le fonctionnement est tellement différant que la résolution l’est aussi …

Résultat, je me retrouve exactement dans la même situation
voici ce que me renvoie la commande ip -4 route

default via 192.168.42.1 dev ens18 onlink
192.168.42.0/24 dev ens18 proto kernel scope link src 192.168.42.21

puis la commande ip addr

1: lo:
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

2: ens18:
mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 86:7d:ba:3d:c2:0f brd ff:ff:ff:ff:ff:ff
altname enp0s18
inet 192.168.42.21/24 brd 192.168.42.255 scope global ens18
valid_lft forever preferred_lft forever

3: wg0:
mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
link/none
inet 10.144.32.47/32 scope global wg0
valid_lft forever preferred_lft forever

il faudrait que les port suivant en cas de communication entrante
Sauf si c’est des requêtes entrantes Sur les ports sur l’interface ens18 ressort par ens18 et non pas le tunnel vpn
80
443
14600:14650
20521
53 pour lest encrypt

j’ai un peu chercher et j’ai pas trouvé …
c’est assez complexe visiblement

merci d’avance pour votre aide

#2

Contenu de la table de routage ?

#3

hello;merci pour la reponse eu
je sais pas comment récupérer sa

alors j’ai un peu cherché j’a ila commande route -n et netstat -nr qui remonte cela

Table de routage IP du noyau
    Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
    0.0.0.0         192.168.42.1    0.0.0.0         UG    0      0        0 ens18
    192.168.42.0    0.0.0.0         255.255.255.0   U     0      0        0 ens18

j’ai aussi la commande ip route qui remonte cela
192.168.42.0/24 dev ens18 proto kernel scope link src 192.168.42.21

je ne sais pas si c’est sa que vous souhaitez ou pas
merci pour la réponse
cordialement

#4

Je préfère le format de la sortie de ip route. Elle est complète ? On ne voit pas la route par défaut affichée par route -n et netstat -nr. Est-ce que le VPN wireguard était actif ? Si oui je suis étonné qu’on ne voie pas de route associée.
A vrai dire je ne connais pas encore wireguard et je ne sais pas comment il gère le routage. Si c’est comme IPSec, ça risque d’être compliqué. Si c’est de façon classique avec des routes, on devrait les voir. Est-ce que ip rule affiche des règles de routage supplémentaires, et si oui, que contiennent les tables de routage cibles (ip route show table NNN) ?

#5

hello

effectivement
ip route ne renvoie que sa pourtant wireguard est bien actif
default via 192.168.42.1 dev ens18 onlink
192.168.42.0/24 dev ens18 proto kernel scope link src 192.168.42.21

route -n renvoie

Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
0.0.0.0         192.168.42.1    0.0.0.0         UG    0      0        0 ens18
192.168.42.0    0.0.0.0         255.255.255.0   U     0      0        0 ens18

netstat -nr renvoie
Table de routage IP du noyau
Destination Passerelle Genmask Indic MSS Fenêtre irtt Iface
0.0.0.0 192.168.42.1 0.0.0.0 UG 0 0 0 ens18
192.168.42.0 0.0.0.0 255.255.255.0 U 0 0 0 ens18

ip rule renvoie
0: from all lookup local
32764: from all lookup main suppress_prefixlength 0
32765: not from all fwmark 0xca6c lookup 51820
32766: from all lookup main
32767: from all lookup default

ip route show table NNN ne renvoie rien sauf
Error: argument "NNN" is wrong: table id value is invalid

pourtant wireguard est bien activé

#6

Il me semblait évident qu’il fallait remplacer « NNN » par le numéro ou le nom effectif de la table de routage référencée par une règle de routage, ici 51820.

Je suppose que les règles 32764 et 32765 sont ajoutées lorsque le VPN monte ?
Les règles que tu avais ajoutées ne sont pas présentes. Les as-tu retirées ou bien est-ce l’activation du VPN qui les a supprimées ?

#7

Oops désoler j’avais pas compris
Les relge que j’ai ajouté ?

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

Hmm je les et retirer voyant quelle ne fonctionner pas
Pour

les règle de parfeu si c’est c’est de ça que l’on parle c’est ufw qui gére
Je vais récupérer ce soir l’information pour
numéro ou le nom effectif de la table de routage référencée par une règle de routage, ici 51820.

Je suppose que les règles 32754 et 32765 sont ajoutées lorsque le VPN monte ?
C’est fort probable je n’est jamais mis de tel règle en place de mon côté

Cordialement

#8

Non, je parle des règles de routage (ip rule). Mais tu peux regarder s’il y a des règles iptables avec la marque 0xca6c (51820) définie dans une des règles de routage.

iptables-save | grep -i -e 51820 -e ca6c

Plan d’action.

  1. Afficher le contenu de la table de routage 51820 :

    ip route show table 51820

  2. Redémarrer le système sans démarrer le VPN et afficher les règles de routage :

    ip rule

  3. Ajouter manuellement les deux règles de routage et la route définies pour openvpn et afficher les règles de routage.

    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

  4. Lancer le VPN wireguard et afficher les règles de routage. Mon hypothèse est que les règles de wireguard vont s’ajouter avant les tiennes et avoir priorité sur elles.

  5. Redémarrer le système et démarrer le VPN.

  6. Ajouter manuellement la règle de routage suivante et afficher les règles de routage. Mon hypothèse est que ta règle va s’ajouter avant celles de wireguard et avoir priorité sur elles.

     ip rule add from 192.168.42.0/24 priority 200 table main
#9

cette commande
ip route show table 51820
affiche
default dev wg0 scope link

ip rule sans vpn donne
0: from all lookup local
32766: from all lookup main
32767: from all lookup default

ip rule après avoir mis les regle

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

 ip rule add from 192.168.42.0/24 priority 200 table main

en place
0: from all lookup local
98: from all lookup main suppress_prefixlength 0
99: not from all fwmark 0xca6c lookup 51820
100: from all to 192.168.42.0/24 lookup main
200: from 192.168.42.0/24 lookup 200
32766: from all lookup main
32767: from all lookup default

  • Ajouter manuellement la règle de routage suivante et afficher les règles de routage. Mon hypothèse est que ta règle va s’ajouter avant celles de wireguard et avoir priorité sur elles.
 ip rule add from 192.168.42.0/24 priority 200 table main

est bah j’i une bonne nouvelle ta methode fonctionne
donc si j’ai bien compris va falloir que je me débrouille pour que les règles

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

ou uniquement

ip rule add from 192.168.42.0/24 priority 200 table main

s’applique après le lancement de wireguard et non avant sous peine qu’il y est un écrasement par wireguard

#10

Bien, tes retours confirment ce que je pensais.

Lorsque wireguard démarre, deux règles de routage sont ajoutées devant la première règle existante (donc en 32764 et 32765 par défaut, ou 98 et 99 si tu as ajouté tes propres règles à partir de 100) parce que les commandes ip rule add qui créent ces règles ne spécifient pas de priorité contrairement aux tiennes.

from all lookup main suppress_prefixlength 0

A pour effet d’appliquer la table de routage normale (main) sauf la route par défaut (dont la destination 0.0.0.0/0 a une longueur de préfixe 0).

not from all fwmark 0xca6c lookup 51820

applique la table de routage 51820 à tous les paquets sauf s’ils ont la marque 0xca6c. Cette table ne contient qu’une route par défaut via l’interface wg0, c’est ce qui fait que le trafic qui n’a pas de route spécifique est envoyé dans le VPN.

Sachant tout cela, plusieurs solutions se dessinent.

Plus besoin des deux règles et de la route dans la table 200, la nouvelle règle indiquée à la fin de mon message précédent devrait suffire si elle est située devant celles de wireguard. Si on veut l’ajouter via une option up dans /etc/network/interfaces, il faut changer la priorité en 0 pour qu’elle soit juste après la règle de la table local et qu’il soit impossible d’insérer de nouvelles règles devant :

up ip rule add from 192.168.42.0/24 priority 0 table main || true

EDIT : je soupçonne que cette méthode perturbe le routage car les deux règles de wireguard vont être créées avec la même priorité 0 dans l’ordre inverse, donc même les paquets destinés au LAN vont être routés par le VPN.

Autre piste : je ne connais pas wireguard, mais il a peut-être un fichier de configuration ou script où figurent les règles qu’il crée, et il est peut-être possible de le modifier pour ajouter la règle supplémentaire. Ce serait l’idéal.

Dernière option : puisque les paquets marqués avec 0xca6c sont exclus du routage via wg0, marquer les paquets à router via la box avec une règle iptables :

iptables -t mangle -A OUTPUT -s 192.168.42.0/24 -j MARK --set-mark 0xca6c
#11

merci pour les infos
c’est super que vous ayez trouvé la solution

si je me souviens bien vous m’aviez dit que (dans post pour openvpn)
que udp ne fonctionnerais pas je crois avec

up ip rule add from 192.168.42.0/24 priority 0 table main || true

avec sa les programme fonctionnent en udp pourront fonctionné ? (juste pour savoir)

iptables -A OUTPUT -s 192.168.42.0/24 -j MARK --set-mark 0xca6c

hmmmm y a t’il un equivalent de

iptables -A OUTPUT -s 192.168.42.0/24 -j MARK --set-mark 0xca6c

mais pour ufw ?

#12

Attention, j’ai modifié mon message précédent pour ajouter une réserve à la première solution.

Ça dépend du programme serveur qui écoute en UDP. UDP a été défini comme un protocole « non connecté », où chaque paquet ou datagramme est indépendant contrairement à TCP où chaque paquet fait partie d’une connexion. Un paquet émis en réponse à un autre paquet n’aura donc pas forcément l’adresse source correspondant à l’adresse destination du paquet auquel il répond. Si le programme ne la spécifie pas, le paquet aura l’adresse source par défaut de l’interface de sortie déterminée par le routage, donc l’adresse de wg0 dans le cas d’un paquet destiné à l’extérieur.

Dans ce cas l’utilisation d’une règle iptables basée sur l’adresse source ne change rien par rapport à une règle de routage basée sur l’adresse source. En revanche une règle iptables basée sur le port source pourrait fonctionner.

Je ne connais pas ufw et j’ignore comment on peut y insérer des règles iptables arbitraire.

#13

ok pas de problème j’ai fais des recherches et ufw n’est pas capable (apparemment) de réagir aussi profondément

donc maintenant plus cas faire en sorte que

iptables -t mangle -A OUTPUT -s 192.168.42.0/24 -j MARK --set-mark 0xca6c

sois lancé au lancement du système je devrais pouvoir trouvé ça seul en principe
mais je me demande si au lieu d’utilisé un script je ne pourrais pas intégré sa dans /etc/network/interfaces

je vais vite fais faire des recherches de monde coté aussi

je crois avoir trouvé
j’ai rajouté

#regle iptable
up iptables -t mangle -A OUTPUT -s 192.168.42.0/24 -j MARK --set-mark 0xca6c

dans /etc/network/interfaces

#14

Tu peux créer la règle iptables avec l’option up. En supposant que ufw ne la fasse pas sauter lorsqu’il applique ses propres règles.
A ta place j’explorerais la piste de la configuration de wireguard avant d’envisager d’autres solutions, ce serait le plus propre.

#15

Hmmm, effectivement, je vais essayer de voir.
Il y a bien un fichier de configuration de configuration pour wirerguard
Situé dans /etc/wireguard/wg0.conf

ufw ne semble pas faire sauté les règles iptables après activation (ce n’est pas plus mal)

Je vais faire quelques recherches, mais dans l’immédiat, ça semble fonctionné.
et effectivement ce n’est pas ce qu’il y a de plus propre j’imagine

#16

Comment le VPN est-il lancé ?

#17

via la comand systctl
systemctl start wg-quick@wg0
il et en auto lancement grâce a systemctl enable wg-quick@wg0 sa a permis de le mettre en lancement automatique

mais je vais finalement évité

up iptables -t mangle -A OUTPUT -s 192.168.42.0/24 -j MARK --set-mark 0xca6c

fait fuité l’ip publique de la box donc des bout de trafique semble passé hors vpn et ceux malgré ufw qui est sensé bloqué les port entré sorti sur ens18 (Sauf pour 443 80 53 et wireguard alors que ça devrait rester derrière le vpn

par contre avec up ip rule add from 192.168.42.0/24 priority 0 table main || true
je n’est pas se problème de fuite et en plus j’ai accès a l’interface web sur le lan

#18

Quelle commande systctl ? Quel rapport avec le lancement du VPN ?
Qu’est-ce qui fait « fuiter l’IP réel » ? (je suppose que tu parles de l’adresse IP publique de la box)

#19

j’ai réédité mon message même moi, je ne pas ce que j’avais écrie, vraiment désolé, pour mon écriture en principe, je vérifie toujours et je passe tout au correcteur.

quand je parle d’ip effectivement je parle de l’ip publique de la box
Mais il semblerait que via ip rule add from 192.168.42.0/24 priority 0 table main || true

Je ne rencontre pas ce souci, et que j’ai accès à mon interface web comme prévu.

donc dans l’immediat mettre cette ligne dans /etc/network/interfaces est la solution (pas vraiment propre j’imagine effectivement)
up ip rule add from 192.168.42.0/24 priority 0 table main || true
Semble donc faire l’affaire dans ma situation.

je vais vérifié pendant quelques temps voir si j’ai des désagréments
mais ce qui est sur c’est que je pense que iptables prend le dessus sur ufw

#20

Tu peux montrer la sortie de ip rule avec la règle créée par l’option up et le VPN monté ?

Si le VPN est lancé avec wg-quick, d’après sa page de manuel on devrait pouvoir utiliser les options PostUp et PreDown dans wg0.conf pour ajouter la règle (sans priorité) lorsque le VPN a démarré et la supprimer lorsqu’il est arrêté.