Я пытаюсь настроить VPN на основе SSH между двумя устройствами, следуя инструкциям на веб-сайте здесь, в лабораторной среде.
Этими двумя устройствами являются Kali Linux 2017.1 (клиент) и Ubuntu Linux Mint 18.2 (сервер). IP-адреса устройств:
- Kali Linux (клиент) - 192.168.56.103, IP-адрес конечной точки VPN: 1.1.1.2
- Linux Mint (сервер) - 192.168.56.102, IP-адрес конечной точки VPN: 1.1.1.1.
Я выполнил следующие шаги на каждом устройстве.
На клиенте,
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 tun0
На сервере,
service ssh start
ip link set tun0 up
ip addr add 1.1.1.1/32 peer 1.1.1.2 dev tun0
Вывод от клиента показан ниже:
$ 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
Вывод с сервера показан ниже:
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)
В то время как IP-адреса туннеля настроены, я не могу передать пинг icmp между двумя IP-адресами - 1.1.1.1, 1.1.1.2
Если я начинаю пинговать с сервера на клиент, я вижу, что клиент получает эхо-запросы от сервера и отвечает, но сервер не получает ответы.
Итак, на сервере я запустил эхо-запросы и проконтролировал ответ 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 64
На клиенте я вижу следующие ответы, отправляемые клиентом в tcpdump, но они не регистрируются сервером
$ 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 64
Может кто-нибудь определить, почему я не могу общаться между клиентом и сервером? Я не могу успешно отправить любой сетевой протокол (не только icmp) между клиентом и сервером.
Я уже пробовал следующее:
На стороне сервера я убедился, что PermitTunnel включен и пользователь root используется в соответствии с требованиями, указанными в документации.
Я удалил все правила брандмауэра iptables и проверил, что политика по умолчанию - ПРИНЯТЬ.
iptables -t nat -F iptables -t filter -F iptables -t mangle -F
Я отключил и удалил UFW для тестирования:
sudo ufw disable sudo apt-get remove ufw
Пробовал искать другие инструкции здесь и здесь, но они не дали мне никаких подсказок о том, что может быть проблема.
Вот мой файл sshd_config с сервера.
# 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 yes
ОБНОВЛЕНИЕ: согласно обратной связи от dirkt, я теперь использовал внутренние IP-адреса. 10.1.1.1 вместо 1.1.1.1, 10.1.1.2 вместо 1.1.1.2. Однако проблема все еще сохраняется.
На клиенте,
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 0
На сервере,
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)
Также вот таблица маршрутизации из команд ip route:
На клиенте,
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 100
На сервере,
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 100
ОБНОВЛЕНИЕ При запуске telnet ясно, что трафик перенаправляется из Kali Linux (клиент) в Linux Mint (сервер), но не наоборот. Даже после того, как порт 12345 открыт на клиенте, пакеты SynAck не регистрируются клиентом вообще.
На сервере мы запускаем следующее:
telnet 10.1.1.1 12345
Trying 10.1.1.1....
На сервере мы видим син пакеты для клиента
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 0
На клиенте мы видим возвращение ответов на сброс, но telnet просто сидит там.
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