☰

SSH VPN - 无法发送 ICMP 数据包来确认 VPN 是否启动

tag-icon • tag-icon linux networking ssh vpn ping
SSH VPN - 无法发送 ICMP 数据包来确认 VPN 是否启动

我正在尝试按照网站上的说明在两台设备之间设置基于 SSH 的 VPN这里在实验室环境中。

这 2 台设备分别是 Kali Linux 2017.1（客户端）和 Ubuntu Linux Mint 18.2（服务器）。设备的 IP 地址为：

  • Kali Linux（客户端） - 192.168.56.103，VPN 端点 IP：1.1.1.2
  • Linux Mint（服务器） - 192.168.56.102，VPN 端点 IP：1.1.1.1。

我已经在每个设备上执行了以下步骤。

在客户端，

sudo ssh -w 0:0 [email protected]
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 后，我无法在 1.1.1.1、1.1.1.2 这两个 IP 之间进行 icmp ping 通信

如果我开始从服务器 ping 到客户端，我可以看到客户端正在接收来自服务器的 ping 并做出响应，但是服务器没有收到回复。

因此在服务器上，我已经启动 ping 并监控 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....

在服务器上，我们看到发往客户端的 syn 数据包

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

答案1

您选择的网络掩码 (255.255.255.255) 没有为主机留出空间。从技术上讲，您的网络地址和广播地址位于同一地址 (10.1.1.1)。我的建议是，如果您想添加更多主机（因为此网络掩码仅为两个主机留出空间），请将网络掩码更改为 255.255.255.252，然后我建议您更改为较低的子网掩码，在 Google 上查找子网计算器以获取更多示例。

相关内容