Accès distant et vpn

Support Debian
#1

Bonjour.
Je ne parviens pas à me connecter sur mon serveur raspbian depuis l’exterieur. J’ai une livebox et une adresse dyndns et redirigé les ports sur ma livebox.
Sur raspbian j’ai installé kodi et un vpn ‹ cyberghodt ›.
Mon vpn ne pourrait-il pas bloquer l’acces distant a mon serveur debian ??
En local aucun problème

J’ai contacté le ‹ chat › de cyberghost qui me dit que effectivement le vpn bloque l’acces distant. Mais selon eux la seule chose à faire est de désactiver le vpn ! Ne peut-on écrire une règle dans iptables autorisant les connexions entrantes sur le reseau vpn ? En admettant qu’on sache de quel reseau il s’agit et qu’il ne change pas toutes les deux minutes.
Je pense que voilà le reseau vpn :

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
      inet 10.203.22.12  netmask 255.255.255.0  destination 10.203.22.12
      inet6 fe80::5218:f3b4:cac:b074  prefixlen 64  scopeid 0x20<link>
      unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100
Cohabitation client OVPN et serveur web
#2

Plus probablement, la route par défaut appliquée par le VPN envoie les paquets de réponse du serveur par le mauvais chemin : le VPN au lieu de la box. ip route le confirmera.

Options possibles :

  • Se connecter au serveur via l’adresse IP de l’interface tun si elle est publique. Ce n’est pas le cas, on oublie.
  • Se connecter au serveur en IPv6 si disponible des deux côtés.
  • Faire du routage avancé sur le serveur pour renvoyer les paquets de réponse via la box. La principale difficulté, c’est d’abord d’identifier ces paquets. Ici on devrait pouvoir identifier les paquets grâce à l’adresse IP source. Ça suffit pour les connexions TCP, pas forcément pour UDP.

En supposant que l’adresse de la box est 192.168.1.1

ip route add default via 192.168.1.1 table 100
ip rule add from 192.168.1.0/24 table 100
ip rule add to 192.168.1.0/24 table main

La dernière règle est nécessaire pour ne pas perturber les communications sur le réseau local. L’ordre des règles est important.

#3

Bonjour.
Çà commence mal !

root@raspberrypi:/home/pi# ip route add default via 192.168.1.1 table 100
RTNETLINK answers: File exists
#4

Tu n’aurais pas exécuté la commande deux fois ?
On peut voir la sortie des commandes suivantes ?

ip route ls table 100
ip rule
#5 
root@raspberrypi:/home/pi# ip route ls table 100
default via 192.168.1.1 dev enxb827ebf0443a
root@raspberrypi:/home/pi# ip rule
0:	from all lookup local 
32766:	from all lookup main 
32767:	from all lookup default
#6

Si l’adresse de la box et le nom de l’interface réseau sont corrects, tu peux passer aux deux commandes ip rule.

#7

C’est fait. Mais je ne sais pas trop bien ce que je suis en train de faire. Je suis complètement aveugle sur ces commandes là !

#8

Le serveur ipv6 est deconnecté sur la box.

#9

Maintenant il faut tester l’accès au serveur depuis l’extérieur via la box avec le VPN actif.

La première commande ajoute une route par défaut via la box dans la table de routage n° 100 (numéro arbitraire).
La seconde ajoute une règle de routage qui applique la table de routage 100 aux paquets dont l’adresse source est dans le réseau local, qui va s’insérer avant la règle qui applique la table de routage principale (main). Les paquets de réponse aux connexions reçues depuis l’extérieur devraient être dans ce cas.
Mais comme les paquets à destination du réseau local peuvent aussi dans ce cas, la dernière commande ajoute une règle de routage qui applique la table de routage normale (main) aux paquets à destination du réseau local, qui va s’insérer avant la précédente.

#10

Bon…j’ai pas tout compris mais ça fonctionne : j’ai accès à mon serveur depuis l’exterieur.

Je vais essayer de comprendre comment tout ça fonctionne…c’est pas gagné.

Merci

Mais au reboot, la route par defaut n’existera plus ? Il faut peut etre l’inscrire dans un fichier ? Interfaces ?

#11

Effectivement, ces commandes ne sont pas persistantes. Les mettre dans le fichier interfaces avec des directives up est une possibilité si l’interface ethernet y est configurée.

#12

Le fichier interfaces est vide. Mon idée tombe à l’eau et moi avec !

En cherchant sur le net j’ai trouvé une autre solution qui consisterait à créer un script dans le répertoire /etc/network/if-up.d
Non, finalement c’est pour le réseau local.

tu me dis que : La première commande ajoute une route par défaut via la box dans la table de routage n° 100
Mais netstat -nr ou route -n ne me renvoie pas de route spécifique !

pi@raspberrypi:~ $ route -n
Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    202    0        0 enxb827ebf0443a
192.168.1.0     0.0.0.0         255.255.255.0   U     202    0        0 enxb827ebf0443a

Et : La seconde ajoute une règle de routage qui applique la table de routage 100…

Je ne trouve pas de commande qui me l’affiche.

Tu peux m’éclairer ?

#13

Bonjour,

Cyberghost est, comme beaucoup d’autres, juste un habillage pour OpenVPN ou WireGuard.

Il faudrait donc déjà par préciser lequel tu utilises entre OpenVPN et WireGuard.

S’il s’agit de Wireguard, il faudra t’assurer avec la commande uname -a que tu possèdes un noyau de version supérieure à 5.6 pour que WireGuard soit intégré.
Si le noyau n’est pas à jour, tu peux faire un sudo apt install --only-upgrade raspberrypi-kernel .

Ensuite, si tu veux pouvoir utiliser le fichier /etc/network/interfaces d’une quelconque manière, il te faudra :

  • modifier le fichier /lib/systemd/system/dhcpcd.service pour faire modifier la ligne avec la directive ExecStart en : ExecStart=/sbin/dhcpcd -q -b
  • demander à systemD de recharger sa configuration avec : sudo systemctl daemon-reload
  • ajouter une ligne au fichier /etc/dhcpcd.conf, du genre denyinterfaces wg0 si tu veux pouvoir utiliser une interface wg0 dans /etc/network/interfaces . On peut mettre plusieurs interfaces en les séparant par des espaces.
  • redémarrer le service dhcpcd avec sudo systemctl restart dhcpcd.service ou en redémarrant tout le système.

Si tu crains de planter tout le système et de ne plus pouvoir accéder à la Raspberry Pi, tu peux prévoir une console série avec un petit adaptateur USB / série à moins de 10 €, qui utilise 3 des broches du bornier.

Sinon, les commandes ifconfig et route sont obsolète sous Linux depuis 2002.

  • pour voir les interfaces réseau : ip link ls
  • pour voir les adresses IPv4 : ip -4 addr ls
  • pour voir les routes de la table de routage « main » : ip -4 route ls
  • pour voir les routes de la table de routage numéro 100 : ip -4 route ls table 100
  • pouvoir les règles de routage : ip -4 rule ls

Etc. Voir https://baturin.org/docs/iproute2/ .

–
AnonymousCoward

#14

J’utilise Wireguard. et le noyau est : Linux raspberrypi 5.10.17-v7+

Par contre PascalHambourg indique que la modification du fichier Intrefaces n’est qu’une des manières de faire et seulement si le l’interface ethernet y est configurée ce qui n’est pas le cas visiblement.
Il y a donc peut-être une autre manière de faire moins ‹ traumatisante › ?

Et merci pour la doc !

#15

Si le serveur tourne avec Raspbian, il me semble que c’est dhcpcd, que je connais très peu, qui est utilisé par défaut pour configurer le réseau. Il faudrait regarder si on peut ajouter des commandes ou des scripts dans sa configuration.

Les scripts /etc/network/if-up.d/ sont utilisés par ifup lors de l’activation d’une interface configurée dans /etc/network/interfaces, donc sans effet si c’est dhcpcd qui gère le réseau.

netstat et route n’affichent que le contenu de la table de routage principale (« main ») qui s’applique par défaut aux destinations non locales ni broadcast. Pour afficher le contenu d’une autre table, il faut utiliser ip route ls comme indiqué dans un message précédent.

Pour afficher les règles de routage il faut utiliser la commande ip rule indiquée dans un message précédent.

#16

Il semblerait qu’il faille créer un fichier de sortie dans /etc qui sera ensuite appelé par dhcpcd.

https://huf.org/wp/?p=355

Ce qu’il y a dans son fichier ne ressemble pas à ce que j’ai dans le mien !?

#17

Mais encore ?

Attention : d’après la page de manuel de dhcpcd-run-hooks (dont je te recommande la lecture si ce n’est pas déjà fait), /etc/dhcpcd.exit-hook est exécuté après chaque action de dhcpcd. Or

  • la route doit être ajoutée uniquement lorsque l’interface ethernet est configurée, soit si $interface = enxb827ebf0443a et $reason = BOUND (si DHCP) ou STATIC
  • et les deux règles ne doivent être ajoutées qu’une seule fois au démarrage, donc si $reason = PREINIT

Enfin, je suppose.

#18

Le début du script correspondrait donc à quelque chose comme çà ?

#!/bin/bash

if [ “${interface}” = “enxb827ebf0443a” ]; then

case “${reason}” in BOUND)

  • les règles citées plus haut ?

Je ne sais pas écrire de script.
Quant au routage je n’ai jamais fait autre chose que d’inscrire une route pour relier deux ordinateurs sur deux réseaux différents.
Là je sors clairement de ma zone de confort !!

Et je ne trouve pas grand chose comme documentation en rapport avec mon cas…

#19

Quelque chose comme ça, oui. Mais je répète que seule la route doit être ajoutée lors de la configuration de l’interface en DHCP ; les règles doivent être ajoutées une fois au démarrage.

Pour la documentation sur le routage avancé, fais une recherche avec « linux advanced routing », tu devrais tomber sur LARTC HOWTO (Linux advanced routing and traffic control). Bon, c’est un peu ardu.

#20

Donc dans le script

donc pas dans le script ?

çà je ne sais pas où le mettre !?