1 votes

Bavarious avatar

VPN à double saut - On ne peut voir que le trafic du réseau local, pas l'internet.

Demandé el 25 de Janvier, 2020
Quand la question a-t-elle été
611 affichage
Nombre de visites la question a
1 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

TLDR : VPN à double saut sur raspberry pi. Peut ssh et voir les partages samba des périphériques locaux sur le VPN. Impossible d'obtenir du trafic internet via le VPN. Je ne sais pas comment procéder.

Mon installation consiste en un seul Raspberry pi qui exécute openvpn y pi-hole . J'ai deux instances d'openvpn :

  • server.conf - Hôte VPN sur tun-incoming . Cela fonctionne, je suis capable de voir les requêtes VPN DNS sur pi-hole .
  • outgoing.conf - se connecter à un fournisseur de VPN sur tun-outgoing . Cela fonctionne localement. Je suis capable de voir une nouvelle IP.

Je suis principalement ce guide : https://www.comparitech.com/blog/vpn-privacy/raspberry-pi-vpn/ L'idée est que je devrais être en mesure de (1) ssh, voir les fichiers partagés, etc. sur tous mes appareils à 192.168.*.* sur mon réseau local et (2) avoir un tunnel Internet à travers le fournisseur VPN. Le premier cas d'utilisation fonctionne bien.

J'ai essayé de le faire selon le guide :

ip rule add from 192.168.1.166 lookup 101
ip route add default via 192.168.1.1 table 101

Après, j'ai perdu la possibilité de me connecter en SSH sur ipv4 .

Vous trouverez ci-dessous quelques résultats pertinents :

liste de routes ip

pi@raspberrypi2:~ $ ip route list
0.0.0.0/1 via 10.1.11.5 dev tun-outgoing
default via 192.168.1.1 dev eth0 src 192.168.1.166 metric 202
10.1.11.1 via 10.1.11.5 dev tun-outgoing
10.1.11.5 dev tun-outgoing proto kernel scope link src 10.1.11.6
10.8.0.0/24 dev tun-incoming proto kernel scope link src 10.8.0.1
128.0.0.0/1 via 10.1.11.5 dev tun-outgoing
192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.166 metric 202
199.229.249.184 via 192.168.1.1 dev eth0

liste de règles ip

pi@raspberrypi2:~ $ ip rule list
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

iptables -t nat -S

pi@raspberrypi2:~ $ sudo iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -m comment --comment openvpn-nat-rule -j MASQUERADE

ifconfig

pi@raspberrypi2:~ $ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.166  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 2604:2000:6aa0:c0d0::307  prefixlen 128  scopeid 0x0<global>
        inet6 fe80::7a09:12ee:27ff:f6fc  prefixlen 64  scopeid 0x20<link>
        inet6 fd38:2d6b:a55b::111  prefixlen 128  scopeid 0x0<global>
        inet6 fd38:2d6b:a55b::307  prefixlen 128  scopeid 0x0<global>
        inet6 fd38:2d6b:a55b:0:3ed3:ce3b:88db:5070  prefixlen 64  scopeid 0x0<global>
        inet6 2604:2000:6aa0:c0d0:70cf:5710:52e:373e  prefixlen 64  scopeid 0x0<global>
        ether dc:a6:32:65:73:5d  txqueuelen 1000  (Ethernet)
        RX packets 48570  bytes 8636380 (8.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 55906  bytes 34181320 (32.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 331  bytes 27074 (26.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 331  bytes 27074 (26.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tun-incoming: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.8.0.1  netmask 255.255.255.0  destination 10.8.0.1
        inet6 fe80::a8c2:d1fa:b798:f945  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 9  bytes 432 (432.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tun-outgoing: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.1.11.6  netmask 255.255.255.255  destination 10.1.11.5
        inet6 fe80::9fe5:8e1:b1c0:86c5  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
        RX packets 24200  bytes 3403386 (3.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 30214  bytes 29464427 (28.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether dc:a6:32:65:73:5e  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
Demandé el 25 de Janvier, 2020 par Bavarious

Réponse

Trop de publicités?

2voto

Utilisateur non enregistré avatar
Utilisateur non enregistré Points 0

TL;DR Vous n'avez pas besoin d'une règle IP. Tout ce dont vous avez besoin ici est une autre règle NAT pour les paquets sortant tun-outgoing interface.

Explication : Ce qui se passe, c'est que le routeur du fournisseur de VPN (ex. 10.1.11.5 dev tun-outgoing ) ne sait pas comment revenir en arrière 10.8.0.0/24 Les paquets sont donc abandonnés/perdus.

Ceci est dû au fait que le réseau 10.8.0.0/24 est connu (c'est-à-dire qu'il est dans la table de routage) par raspberrypi2 mais il est inconnu de tout autre hôte ne faisant pas partie du même VPN (comme les hôtes du réseau local et le fournisseur de VPN externe).

Si l'on considère uniquement le deuxième cas d'utilisation que vous avez mentionné (utiliser le fournisseur de VPN pour surfer sur Internet), en théorie vous avez deux façons de résoudre ce problème :

  1. En configurant (statiquement/automatiquement) une route dans chaque hôte que vous devez atteindre depuis l'intérieur de votre VPN ( tun-incoming )
  2. Ou, en masquant l'IP à l'aide de NAT

La première méthode est évidemment pas réalisable en présence d'acteurs externes (le fournisseur VPN), donc vous pouvez résoudre ce problème seulement en créant une règle NAT comme ceci :

-A POSTROUTING -s 10.8.0.0/24 -o tun-outgoing -j MASQUERADE

Cette règle masquera toutes les connexions de votre VPN. 10.8.0.0/24 à l'internet via VPN en utilisant l'adresse IP (source) de l'ordinateur. raspberrypi2 qui est connu par le fournisseur de VPN.

Premier cas d'utilisation (accès au réseau local) : Pour le premier cas d'utilisation, vous pouvez (et c'est effectivement le cas) toujours utiliser la méthode NAT, mais la méthode 2 peut également être applicable. Pour l'appliquer, si raspberrypi2 est la passerelle par défaut du réseau local, vous pouvez simplement supprimer la règle NAT et tout fonctionnera correctement.

Si rasperrypi2 es pas la passerelle par défaut du réseau local, vous pouvez toujours appliquer la méthode 2 :

  • configurer une route statique dans la passerelle par défaut actuelle du LAN
  • ou, en configurant une route statique dans chaque hôte du réseau local

(les deux, évidemment, pointant vers raspberrypi2 uniquement pour le 10.8.0.0/24 sous-réseau).

Répondu el 2 de Février, 2020 par Utilisateur non enregistré (0 Points )

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X