SSH VPN - не может отправлять ICMP-пакеты для подтверждения работоспособности VPN

Question

Я пытаюсь настроить 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

score 1 · Answer 1 · 2011-03-09T19:38:42

Выбранная вами маска сети (255.255.255.255) не оставляет места для хостов. Технически у вас есть сетевой адрес и широковещательный адрес на одном и том же адресе (10.1.1.1). Я рекомендую изменить маску сети на 255.255.255.252, если вы хотите добавить больше хостов (так как эта маска маски оставляет место только для двух хостов), тогда я рекомендую вам перейти к поиску подсетей в Google для подсетей-калькуляторов для дальнейших примеров. ,

Сейчас выбран русский

SSH VPN - не может отправлять ICMP-пакеты для подтверждения работоспособности VPN

1 ответ1

Всё ещё ищете ответ? Посмотрите другие вопросы с метками linux networking ssh vpn ping.

SSH VPN - не может отправлять ICMP-пакеты для подтверждения работоспособности VPN

1 ответ1

Всё ещё ищете ответ? Посмотрите другие вопросы с метками linux networking ssh vpn ping.

Похожие