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 を経由すべきではないですよね?

VPN をオフにすると次のようになります netstat -r:

$ 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 state UNKNOWN group default qlen 3 link/ppp inet 172.16.203.173 peer 192.0.2.1/32 scope global ppp0 valid_lft forever preferred_lft forever

    -> 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 に上書きされます。第二号

2番目の問題を解決するためにインストールしましたdnsmasqこれはプロキシとして機能し、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 ((保護を解除、デフォルトモード)) - ロールバックする

誰かの役に立つことを願っています。

関連情報