Arch Linux VPN + L2TP:连接已建立,互联网可以工作但无法访问内部网络

Arch Linux VPN + L2TP:连接已建立,互联网可以工作但无法访问内部网络

我根据配置VPN指令(我有 Linux),一切都很好,连接建立,IP 地址从我的变为美国的,但是通过 VPN 应该可用的资源仍然不可用。

根据相同的说明设置相同的连接,但仅适用于 Windows 10 - 一切正常,资源可用。在 Linux 上,到这些资源的流量不会通过 VPN 服务器,但我仍然无法弄清楚如何修复它,因为我在这方面并不擅长。我的系统信息:

$ cat /etc/*release
NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://www.archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://bugs.archlinux.org/"
LOGO=archlinux

我的假设是流量绕过 VPN 服务器并通过默认网关。

以下是 nslookup 显示的内容

$nslookup confluence.internal.mycompany.com
Server:    8.8.8.8
Address:  8.8.8.8#53

我认为尝试一下是有意义的路由,但我不擅长网络管理,也不知道如何确定正确的子集地址。例如 aaa.internal.mycompany.com、bbb.internal.mycompany.com、ccc.internal.mycompany.com 等。我想通过 VPN 将流量导向 aaa、bbb、ccc,该怎么做?

以下 tcpdump 信息可能对您有帮助:

13:57:39.163855 IP 172.16.203.173.41032 > 8.8.8.8.53: 44676+ A? confluence.internal.mycompnay.com. (50)

00:06:11.353064 IP 172.16.203.173.39547 > 8.8.4.4.53: 13730+ A? confluence.internal.mycompany.com. (50)
00:06:11.484299 IP 172.217.1.46.443 > 172.16.203.173.35770: Flags [P.], seq 1:40, ack 39, win 269, options [nop,nop,TS val 1580986377 ecr 1105408237], length 39
00:06:11.484400 IP 172.16.203.173.35770 > 172.217.1.46.443: Flags [.], ack 40, win 502, options [nop,nop,TS val 1105408387 ecr 1580986377], length 0
00:06:11.525396 IP 8.8.4.4.53 > 172.16.203.173.39547: 13730 NXDomain 0/1/0 (113)
00:06:11.525562 IP 172.16.203.173.39547 > 8.8.4.4.53: 32697+ AAAA? confluence.internal.mycompany.com. (50)
00:06:11.697698 IP 8.8.4.4.53 > 172.16.203.173.39547: 32697 NXDomain 0/1/0 (113)
00:06:11.698212 IP 172.16.203.173.48215 > 8.8.8.8.53: 13821+ A? confluence.internal.mycompany.com. (50)
00:06:11.698276 IP 172.16.203.173.48215 > 8.8.8.8.53: 19952+ AAAA? confluence.internal.mycompany.com. (50)
00:06:11.859694 IP 8.8.8.8.53 > 172.16.203.173.48215: 13821 NXDomain 0/1/0 (113)
00:06:11.872141 IP 8.8.8.8.53 > 172.16.203.173.48215: 19952 NXDomain 0/1/0 (113)
00:06:11.873004 IP 172.16.203.173.49336 > 8.8.8.8.53: 36616+ A? confluence.internal.mycompany.com. (50)
00:06:12.034300 IP 8.8.8.8.53 > 172.16.203.173.49336: 36616 NXDomain 0/1/0 (113)
00:06:12.034472 IP 172.16.203.173.49336 > 8.8.8.8.53: 34317+ AAAA? confluence.internal.mycompany.com. (50)
00:06:12.195798 IP 172.16.203.173.33819 > 8.8.8.8.53: 61396+ A? translate.google.com. (38)
00:06:12.197393 IP 172.16.203.173.49098 > 216.58.192.206.443: Flags [P.], seq 2343637690:2343638004, ack 443265426, win 11148, options [nop,nop,TS val 2103047503 ecr 1587334695], length 314
00:06:12.209082 IP 8.8.8.8.53 > 172.16.203.173.49336: 34317 NXDomain 0/1/0 (113)
00:06:12.209542 IP 172.16.203.173.54539 > 8.8.8.8.53: 62574+ A? confluence.internal.mycompany.com. (50)
00:06:12.209658 IP 172.16.203.173.54539 > 8.8.8.8.53: 56421+ AAAA? confluence.internal.mycompany.com. (50)
00:06:12.334328 IP 172.16.203.173.56738 > 172.217.6.2.443: Flags [P.], seq 1835541891:1835541930, ack 3334813663, win 502, options [nop,nop,TS val 324800469 ecr 1444482233], length 39
00:06:12.334456 IP 172.16.203.173.56978 > 216.58.192.130.443: Flags [P.], seq 712232265:712232304, ack 2284899148, win 502, options [nop,nop,TS val 1560658341 ecr 3970133710], length 39
00:06:12.334525 IP 172.16.203.173.56994 > 172.217.4.37.443: Flags [P.], seq 175676537:175676576, ack 336787689, win 24353, options [nop,nop,TS val 525175697 ecr 3037756038], length 39
00:06:12.334592 IP 172.16.203.173.45234 > 172.217.8.195.443: Flags [P.], seq 840900759:840900798, ack 624615808, win 1323, options [nop,nop,TS val 2439520764 ecr 528658266], length 39
00:06:12.348814 IP 216.58.192.206.443 > 172.16.203.173.49098: Flags [.], ack 314, win 1050, options [nop,nop,TS val 1587377915 ecr 2103047503], length 0
00:06:12.358256 IP 8.8.8.8.53 > 172.16.203.173.33819: 61396 2/0/0 CNAME www3.l.google.com., A 216.58.192.206 (75)
00:06:12.358483 IP 172.16.203.173.39682 > 8.8.8.8.53: 10206+ AAAA? translate.google.com. (38)
00:06:12.370884 IP 8.8.8.8.53 > 172.16.203.173.54539: 56421 NXDomain 0/1/0 (113)
00:06:12.382054 IP 8.8.8.8.53 > 172.16.203.173.54539: 62574 NXDomain 0/1/0 (113)

我说得对吗?这不正确?流量不应该通过 Google 的 DNS,对吗?

netstat -r关闭 VPN 后的情况如下 :

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    600    0        0 wlp2s0
192.168.0.0     0.0.0.0         255.255.255.0   U     600    0        0 wlp2s0

开启 VPN 后:

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         0.0.0.0         0.0.0.0         U     500    0        0 ppp0
0.0.0.0         192.168.0.1     0.0.0.0         UG    600    0        0 wlp2s0
192.0.2.1       0.0.0.0         255.255.255.255 UH    500    0        0 ppp0
192.168.0.0     0.0.0.0         255.255.255.0   U     600    0        0 wlp2s0
192.168.0.1     0.0.0.0         255.255.255.255 UH    600    0        0 wlp2s0
208.100.17.99   192.168.0.1     255.255.255.255 UGH   600    0        0 wlp2s0

我试过但失败了:我失去了互联网连接

这是我的网络管理器中的 VPN 设置:

在此处输入图片描述 在此处输入图片描述 在此处输入图片描述

我该如何解决此问题?

答案1

我想通过 VPN 将流量引导至 aaa、bbb、ccc,该怎么做?

我假设这些是本地地址(正如您在标题中所述),例如192.168.0.2。发往该地址的数据包不会通过隧道接口,因为您有一条比指向以下地址的默认路由更具体的路由wlp2s0

192.168.0.1     0.0.0.0         255.255.255.255 UH    600    0        0 wlp2s0

使用静态路由时,更具体的路由总是“获胜”。要解决此问题,您可以执行以下操作:

  1. 使用以下方法删除当前路线ip route delete 192.168.0.1
  2. 向该前缀(寻址 aaa、bbb、cc 主机)添加新路由,并将接口 ( dev) 指向隧道接口。例如: ip route add 192.168.0.1/24 via $IP_OF_TUNNELGATEWAY dev ppp0

答案2

最后,我解决了我的问题。说来话长。根本原因是错误的 DNS 配置,导致内部(VPN 服务器后面)地址无法正确解析。发生这种情况的原因假设如下。每次我连接到 VPN 时,都会发生以下一系列事件:

  1. -> 网络管理器

    ->斯特朗斯旺点对点0

    -> dhclient ppp0 (172.16.203.173, 192.0.2.1, dns1=xyz11, dns2=xyz12) -> resolvconf

    ppp0:<POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc fq_codel 状态 UNKNOWN 组默认 qlen 3 link/ppp inet 172.16.203.173 对等体 192.0.2.1/32 范围全局 ppp0 valid_lft 永远 preferred_lft 永远

    -> dns1=xyz11,dns2=xyz12 到 /etc/resolv.conf

DNS 地址取自 VPN 连接配置(见上面的屏幕截图)。

  1. 路由表中添加了一条新路由default via ppp0 metric 500。其优先级低于默认的 enp3s0 优先级,0.0.0.0 192.168.0.1 0.0.0.0 UG 100 0 0 enp3s0因此没有流量通过 ppp0。首要问题

  2. 包含 dns1 和 dns2 的 /etc/resolv.conf 在某些时间点会被网络管理器用默认的 google dns 8.8.8.8 和 8.8.4.4 覆盖。第二期

为了解决第二个问题,我安装了域名系统它充当代理并自行处理 DNS。我不得不卸载pacman -R openresolv netctl它,它发生了变化/etc/resolv.conf,但它不包含 dnsmasq 的唯一地址:

# Generated by NetworkManager
search internal.mycompany.com
nameserver 127.0.0.1
options edns0 trust-ad

为了说明网络管理器使用 dnsmarq,我还添加了此行/etc/NetworkManager/conf.d/dns.conf

[main]
dns=dnsmasq

为了解决 NetworkManager 中的第一个问题,我添加了一条比默认 enp3s0 路由优先级更高的更具体的路由:

10.Y.X.Z    192.0.2.1       255.255.255.255 UGH   500    0        0 ppp0

就是这样。所有到内部资源的流量都通过 VPN,其余流量按先前的方式流动。

另外,我拒绝覆盖 /etc/resolv.conf

chattr +i /etc/resolv.conf ((to protect the file from write))

chattr -i /etc/resolv.conf ((取消保护,默认模式)) - 回滚

希望它对某人有帮助。

相关内容