我正在尝试按照网站上的说明在两台设备之间设置基于 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 上查找子网计算器以获取更多示例。