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

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 上查找子网计算器以获取更多示例。

相关内容