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等。

這裡還有可能有幫助的 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 狀態未知群組預設 qlen 3 link/ppp inet 172.16.203.173 對等體 192.0.2.1/32 永遠

    -> 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 在某個時間點被網路管理員覆蓋,預設 googles 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/resolve.conf 進行任何覆蓋

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

chattr -i /etc/resolv.conf ((取消保護,預設模式)) - 回滾

希望它對某人有幫助。

相關內容