J'ai crée un vpn avec ssh et interface tun, mais que peut-on faire avec?

,
Tags: #<Tag:0x00007f46aed6b310> #<Tag:0x00007f46aed6b130>

Bonjour à tous et à toutes,

j’ai crée un vpn avec mon vps en utilisant ssh et l’interface tun, mais une fois que j’ai crée mon vpn, je ne sais pas comment je pourrais l’utiliser pour naviguer sur internet à partir de mon poste client (comme nordvpn qui te propose d’utiliser un vpn pour naviguer en sécurité depuis ton poste client).

Voici les commandes ci-dessous que j’ai tapé pour créer un vpn.

Sur le vps

Dans le fichier /etc/ssh/sshd_config, autorisons le tunnel :

PermitTunnel yes

Puis redémarrer le serveur sshd :

# systemctl restart sshd

Ensuite, on crée l’interface virtuelle tun0 en mode tunnel (dit aussi mode « point-to-point ») :

# ip tuntap add dev tun0 mod tun

Puis on attribue une adresse ip privée (10.0.0.1/32) à cette interface tun0, en lui spécifiant en plus l’adresse ip privée de l’autre point du tunnel (10.0.0.2) avec qui elle doit créer un tunnel :

# ip addr add 10.0.0.1/32 peer 10.0.0.2 dev tun0

Puis on active cette interface tun0 :

# ip link set tun0 up

Du coup, en tapant ip addr, on voit bien l’interface tun0 d’adresse ip 10.0.0.1, prêt à communiquer avec l’autre point du tunnel d’adresse ip 10.0.0.2 :

$ ip addr
....
3: tun0: <NO-CARRIER,POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 500
    link/none 
    inet 10.0.0.1 peer 10.0.0.2/32 scope global tun0
       valid_lft forever preferred_lft forever

La conséquence de cela, est qu’une route a été ajouté à l’interface tun0, et qui route les paquets vers « l’autre point » du tunnel, càd vers 10.0.0.2 :

$ ip route

10.0.0.2 dev tun0 proto kernel scope link src 10.0.0.1

Sur le client (mon ordinateur personnel par exemple)

On crée l’autre point du tunnel, en créant l’interface virtuelle tun0 :

# ip tuntap add dev tun0 mod tun

Puis on attribue une adresse ip privée (10.0.0.2/32) à cette interface tun0, en lui spécifiant en plus l’adresse ip privée de l’autre point du tunnel (10.0.0.1, qui est celui de tun0 du vps) avec qui elle doit créer un tunnel :

# ip addr add 10.0.0.2/32 peer 10.0.0.1 dev tun0

Puis on active cette interface tun0 :

# ip link set tun0 up

Du coup, en tapant ip addr, on voit bien l’interface tun0 d’adresse ip 10.0.0.2, prêt à communiquer avec l’autre point du tunnel d’adresse ip 10.0.0.1 (qui est le vps) :

$ ip addr
....
3: tun0: <NO-CARRIER,POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 500
    link/none 
    inet 10.0.0.2 peer 10.0.0.1/32 scope global tun0
       valid_lft forever preferred_lft forever

La conséquence de cela, est qu’une route a été ajouté à l’interface tun0, et qui route les paquets vers « l’autre point » du tunnel, càd vers 10.0.0.1 (qui est le vps) :

$ ip route

10.0.0.1 dev tun0 proto kernel scope link src 10.0.0.2

Enfin, on crée le tunnel entre tun0 du client et tun0 du vps :

$ ssh -w 0:0 user@ip_publique_vps

Puis, on fait un ping sur l’adresse ip de l’interface tun0 du serveur (vps) :

$ ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=30.5 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=30.1 ms
64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=32.3 ms

=> donc ça marche

De même, dans le terminal du vps, on fait un ping sur l’adresse ip de l’interface tun0 du client :

$ ping 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=30.5 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=30.1 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=32.3 ms

=> donc ça marche

Bonus :
Imaginons que mon vps fait aussi partie d’un réseau privé 192.168.0.0/24, et a comme adresse ip privée 192.168.0.1 (par son interface ethernet ens3 par exemple), je peux accéder de façon sécurisée à ce réseau privé 192.168.0.0/24 distant depuis mon poste client en passant par le tunnel. Pour cela, sur mon poste client, il suffit d’ajouter une route à l’interface tun0 du vps :

# ip route add 192.168.0.0/24 via 10.0.0.1

Mais voilà, comment mon poste client pourrait utiliser ce vpn pour naviguer sur internet (comme le font les utilisateurs de nordvpn), de sorte que l’adresse ip source ne sera plus celle de la box internet du client, mais l’adresse ip du vps ???

Merci d’avance.

Pas tout à fait exact:
Un VPN crée un tunnel sécurisé entre l’ordinateur d’un utilisateur et le serveur VPN qui masque son activité en ligne et son emplacement. La sécurité VPN permet aux utilisateurs de protéger leur confidentialité en ligne et d’empêcher leur fournisseur de services Internet (FAI) de suivre leur activité de navigation .

Il ne peut pas empêcher le suivi des cookies, les virus ou les programmes malveillants, et il ne peut pas se protéger contre les tentatives d’hameçonnage. Des fuites de données peuvent se produire. Mais plus important encore, un VPN est uniquement aussi sécurisé que l’entreprise qui l’exécute, y compris l’utilisateur.

Merci pour ta réponse.

Donc le tunnel du vpn permet à mon poste client de se connecter à un réseau privé distant (comme le réseau privé d’une entreprise) sans que le FAI de mon poste client sache quoi que ce soit car le tunnel est « chiffré » ??

Oui c’est ça.
mais pour ce qui est des NodVPN pour ta navigation internet de chez toi, c’est pareil, mais avec moins de sécurité que celle de ton entreprise.

Bien évidement un VPN via ton entreprise ne te permet pas du tout de naviguer en toute confidentialité vis à vis de celle-ci.

1 J'aime

Donc quand NordVPN dit qu’en utilisant son vpn, je pourrais utiliser une machine géographiquement différent (par exemple en Pologne) pour naviguer sur internet, en fait c’est un tunnel entre mon poste client et un proxy ??

basiquement, il n’est pas sensé y avoir de proxy. C’est juste que ton adresse d’origine de tes requêtes internet sera en Pologne.
Mais rien ne permet d’affirmer hors les promesse faite par NordVPN qu’il n’y a pas de proxy et qu’ils n’enregistrent rien.
NordVPN semble être le plus fiable, mais il ne faut pas oublier qu’il a à minima, l’adresse de courriel, le nom et le prénom de l’utilisateur ainsi que la carte bleue utilisée pour payer et bien sur le pays de résidence (pour l’application de la TVA)…
Sachant que Carte Bleue ne se gêne pas pour vendre les données collectées (à moins qu’ils n’aient changé de pratique mais j’en doute).

Dopn,c anonymat relatif et confidentialité relative. L’important c’est quoi veut-on se protéger réellement avec un VPN.
Il n’est pas possible d’être complètement anonyme sur Internet quoiqu’on fasse. Quand à la confidentialité, elle dépend du bon vouloir de toutes les entités et équipements intermédiaires.

Le meilleur anonymat et la meilleure confidentialité est bien évidement de ne pas aller sur Internet ou alors de pirater des système, de ne pas utiliser d’authentification, et de ne rien payer; mais ce n’est pas à la portée du quidam venu. Et encore, certains se font quand même prendre.

Merci pour ta réponse.

Du coup, j’ai l’impression que le mot VPN est un mot « marketing » pour en faite vendre aux clients des tunnels chiffrés vers des proxy web (comme proxy socks5), et non des VPN.

Car pour moi, un VPN c’est plus un tunnel chiffré de site-à-site (ou de réseau locale à réseau locale).

L’avantage d’un serveur VPN installé sur un serveur dédié (ou sur un vps), est que je peux utiliser tout simplement son adresse ip tun0 (au lieu de l’adresse ip publique du serveur dédié) pour faire par exemple du ftp sans ssl à travers le tunnel

C’est plus complexe.
Un tunnel te fait communiquer entre deux entités distinctes dans un mode chiffré, un tunnel chiffré, mais en restant deux entités distinctes.

Un VPN te permet de faire parti d’une entité à distance. Ton PC fait parti du réseau local distant. Il n’y a plus d’entité distinctes entre les deux hors les règles rétablies dans la génération du VPN.

1 J'aime