J'essaie de mettre en place un VPN basé sur SSH entre 2 appareils, en suivant les instructions du site web. aquí dans un environnement de laboratoire.
Les 2 appareils sont Kali Linux 2017.1 (client), et Ubuntu Linux Mint 18.2 (serveur). Les adresses IP des appareils sont :
- Kali Linux (client) - 192.168.56.103, IP du point de terminaison VPN : 1.1.1.2
- Linux Mint (serveur) - 192.168.56.102, IP du point de terminaison VPN : 1.1.1.1.
J'ai effectué les étapes suivantes sur chaque appareil.
Sur le client,
sudo ssh -w 0:0 root@192.168.56.102
ip link set tun0 up
ip addr add 1.1.1.2/32 peer 1.1.1.1 dev tun0Sur le serveur,
service ssh start
ip link set tun0 up
ip addr add 1.1.1.1/32 peer 1.1.1.2 dev tun0La sortie du client est indiquée ci-dessous :
$ ifconfig tun0
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 1.1.1.2 netmask 255.255.255.255 destination 1.1.1.1
inet6 fe80::73bc:5f32:6ba2:9419 prefixlen 64 scopeid 0x20<link>
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC)
RX packets 597 bytes 50040 (48.8 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 602 bytes 50280 (49.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 La sortie du serveur est indiquée ci-dessous :
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:1.1.1.1 P-t-P:1.1.1.2 Mask:255.255.255.255
inet6 addr: fe80::d0f:d97a:3bc0:c1ad/64 Scope:Link
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:671 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 B) TX bytes:56256 (56.2 KB)Alors que les IP du tunnel sont configurées, je suis incapable de communiquer des pings icmp entre les 2 IP - 1.1.1.1, 1.1.1.2.
Si je lance un ping du serveur vers le client, je peux voir que le client reçoit les pings du serveur et répond, mais que le serveur ne reçoit pas les réponses.
Donc sur le serveur, j'ai commencé les pings et surveillé la réponse de tcpdump.
$ ping 1.1.1.2
$ sudo tcpdump -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
03:07:01.494334 IP 1.1.1.1 > 1.1.1.2: ICMP echo request, id 8371, seq 810, length 64
03:07:02.517661 IP 1.1.1.1 > 1.1.1.2: ICMP echo request, id 8371, seq 811, length 64
03:07:03.541852 IP 1.1.1.1 > 1.1.1.2: ICMP echo request, id 8371, seq 812, length 64Sur le client, je vois les réponses suivantes envoyées par le client dans tcpdump, mais elles ne sont pas enregistrées par le serveur
$ tcpdump -ni tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
03:09:48.485679 IP 1.1.1.1 > kali: ICMP echo request, id 8371, seq 1125, length 64
03:09:48.485711 IP kali > 1.1.1.1: ICMP echo reply, id 8371, seq 1125, length 64
03:09:49.510028 IP 1.1.1.1 > kali: ICMP echo request, id 8371, seq 1126, length 64
03:09:49.510052 IP kali > 1.1.1.1: ICMP echo reply, id 8371, seq 1126, length 64Quelqu'un peut-il expliquer pourquoi je ne parviens pas à communiquer entre le client et le serveur ? Je ne parviens pas à envoyer un protocole réseau (pas seulement icmp) entre le client et le serveur.
J'ai déjà essayé ce qui suit :
-
Côté serveur, je me suis assuré que PermitTunnel est activé et que l'utilisateur root est utilisé conformément aux exigences énoncées dans la documentation.
-
J'ai supprimé toutes les règles du pare-feu iptables et vérifié que la politique par défaut est ACCEPT.
iptables -t nat -F iptables -t filter -F iptables -t mangle -F -
J'ai désactivé et supprimé l'ufw pour le tester :
sudo ufw disable sudo apt-get remove ufw -
J'ai essayé de chercher d'autres instructions aquí y aquí mais ils ne m'ont donné aucun indice sur ce que pourrait être le problème.
Voici mon fichier sshd_config du serveur.
# Package generated configuration file
# See the sshd_config(5) manpage for details
# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes
# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024
# Logging
SyslogFacility AUTH
LogLevel INFO
# Authentication:
LoginGraceTime 120
#PermitRootLogin prohibit-password
PermitRootLogin yes
PermitTunnel yes
StrictModes yes
GatewayPorts yes
AllowTcpForwarding yes
RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes
# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no
# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes
# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
#MaxStartups 10:30:60
#Banner /etc/issue.net
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yesUPDATE : Selon les commentaires de Dirkt, j'ai maintenant utilisé des adresses IP internes. 10.1.1.1 au lieu de 1.1.1.1, 10.1.1.2 au lieu de 1.1.1.2. Cependant, le problème persiste.
Sur le client,
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 10.1.1.1 netmask 255.255.255.255 destination 10.1.1.2
inet6 fe80::23ca:f7ce:e4c7:24c8 prefixlen 64 scopeid 0x20<link>
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC)
RX packets 316 bytes 26436 (25.8 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 320 bytes 26628 (26.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Sur le serveur,
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.1.1.2 P-t-P:10.1.1.1 Mask:255.255.255.255
inet6 addr: fe80::e633:5f17:9b14:ae06/64 Scope:Link
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:191 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 B) TX bytes:15936 (15.9 KB)Voici également la table de routage issue des commandes ip route :
Sur le client,
default via 10.0.2.2 dev eth0
10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15
10.1.1.2 dev tun0 proto kernel scope link src 10.1.1.1
192.168.56.0/24 dev eth1 proto kernel scope link src 192.168.56.103
192.168.56.0/24 dev eth1 proto kernel scope link src 192.168.56.103 metric 100Sur le serveur,
default via 10.0.2.2 dev enp0s3 proto static metric 100
10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15 metric 100
10.1.1.1 dev tun0 proto kernel scope link src 10.1.1.2
169.254.0.0/16 dev enp0s3 scope link metric 1000
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.18.0.0/16 dev br-56e99b53b1be proto kernel scope link src 172.18.0.1 linkdown
192.168.56.0/24 dev enp0s8 proto kernel scope link src 192.168.56.102 metric 100UPDATE En exécutant telnet, il est clair que le trafic est transféré de Kali Linux (client) à Linux Mint (serveur), mais pas l'inverse. Même après l'ouverture du port 12345 sur le client, les paquets SynAck ne sont pas du tout enregistrés par le client.
Sur le serveur, nous exécutons ce qui suit :
telnet 10.1.1.1 12345
Trying 10.1.1.1....Sur le serveur, nous voyons des paquets syn pour le client.
tcpdump -ni tun0
root@linuxmint-VirtualBox /home/linuxmint # tcpdump -ni tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
17:47:28.869970 IP 10.1.1.2.49674 > 10.1.1.1.12345: Flags [S], seq 2551141293, win 29200, options [mss 1460,sackOK,TS val 2598500 ecr 0,nop,wscale 7], length 0
17:47:29.874205 IP 10.1.1.2.49674 > 10.1.1.1.12345: Flags [S], seq 2551141293, win 29200, options [mss 1460,sackOK,TS val 2598752 ecr 0,nop,wscale 7], length 0
17:47:31.890376 IP 10.1.1.2.49674 > 10.1.1.1.12345: Flags [S], seq 2551141293, win 29200, options [mss 1460,sackOK,TS val 2599256 ecr 0,nop,wscale 7], length 0Sur le client, nous voyons les réponses de réinitialisation revenir, mais telnet ne bouge pas.
tcpdump -ni tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
17:47:18.918860 IP 10.1.1.2.49676 > 10.1.1.1.12345: Flags [S], seq 3064866770, win 29200, options [mss 1460,sackOK,TS val 2605333 ecr 0,nop,wscale 7], length 0
17:47:18.918899 IP 10.1.1.1.12345 > 10.1.1.2.49676: Flags [R.], seq 0, ack 3064866771, win 0, length 0
17:47:19.921367 IP 10.1.1.2.49676 > 10.1.1.1.12345: Flags [S], seq 3064866770, win 29200, options [mss 1460,sackOK,TS val 2605584 ecr 0,nop,wscale 7], length 0
17:47:19.921412 IP 10.1.1.1.12345 > 10.1.1.2.49676: Flags [R.], seq 0, ack 1, win 0, length 0
