Arch Linux VPN + L2TP: Verbindung hergestellt, Internet funktioniert, aber kein Zugriff auf das interne Netzwerk

Question 1

Ich möchte den Datenverkehr über das VPN an aaa, bbb und ccc weiterleiten. Wie geht das?

Ich gehe davon aus, dass es sich hier um lokale Adressen handelt (wie Sie im Titel behaupten), z. B. 192.168.0.2. Pakete an diese Adresse gehen nicht durch die Tunnelschnittstelle, da Sie eine spezifischere Route haben als die Standardroute, die auf Folgendes verweist wlp2s0:

192.168.0.1     0.0.0.0         255.255.255.255 UH    600    0        0 wlp2s0

Beim statischen Routing „gewinnen“ immer die spezifischeren Routen. Um dieses Problem zu lösen, können Sie Folgendes tun:

Löschen Sie die aktuelle Route mitip route delete 192.168.0.1
Fügen Sie diesem Präfix (das die Hosts aaa, bbb und cc adressiert) eine neue Route hinzu, wobei die Schnittstelle ( dev) auf die Tunnelschnittstelle zeigt. Beispiel: ip route add 192.168.0.1/24 via $IP_OF_TUNNELGATEWAY dev ppp0

Answer

Ich möchte den Datenverkehr über das VPN an aaa, bbb und ccc weiterleiten. Wie geht das?

Ich gehe davon aus, dass es sich hier um lokale Adressen handelt (wie Sie im Titel behaupten), z. B. 192.168.0.2. Pakete an diese Adresse gehen nicht durch die Tunnelschnittstelle, da Sie eine spezifischere Route haben als die Standardroute, die auf Folgendes verweist wlp2s0:

192.168.0.1     0.0.0.0         255.255.255.255 UH    600    0        0 wlp2s0

Beim statischen Routing „gewinnen“ immer die spezifischeren Routen. Um dieses Problem zu lösen, können Sie Folgendes tun:

Löschen Sie die aktuelle Route mitip route delete 192.168.0.1
Fügen Sie diesem Präfix (das die Hosts aaa, bbb und cc adressiert) eine neue Route hinzu, wobei die Schnittstelle ( dev) auf die Tunnelschnittstelle zeigt. Beispiel: ip route add 192.168.0.1/24 via $IP_OF_TUNNELGATEWAY dev ppp0

Question 2

Endlich habe ich mein Problem gelöst. Es ist eine lange Geschichte. Die Grundursache ist die falsche DNS-Konfiguration, wodurch interne (hinter dem VPN-Server liegende) Adressen nicht richtig aufgelöst werden konnten. Eine Vermutung, warum das passiert ist, ist die folgende. Jedes Mal, wenn ich mich mit VPN verbinde, passiert die folgende Ereigniskette:

-> Netzwerkmanager

->starker Schwanppp0

-> 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 Status UNBEKANNT Gruppe Standard qlen 3 Link/ppp inet 172.16.203.173 Peer 192.0.2.1/32 Bereich global ppp0 valid_lft für immer preferred_lft für immer

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

DNS-Adressen wurden aus der VPN-Verbindungskonfiguration übernommen (siehe Screenshot oben).

Der Routing-Tabelle wurde eine neue Route default via ppp0 metric 500hinzugefügt. Ihre Priorität ist niedriger als die Standardpriorität von enp3s0, 0.0.0.0 192.168.0.1 0.0.0.0 UG 100 0 0 enp3s0daher fließt kein Datenverkehr über ppp0.erste Ausgabe
/etc/resolv.conf, das DNS1 und DNS2 enthält, wird irgendwann vom Netzwerkmanager durch die Standard-Google-DNS 8.8.8.8 und 8.8.4.4 überschrieben.zweite Ausgabe

Um das zweite Problem zu beheben, installierte ichDNS-MASQdas als Proxy dient und DNS selbst verwaltet. Ich musste es deinstallieren, pacman -R openresolv netctlwas sich änderte /etc/resolv.conf, und jetzt enthält es die einzige Adresse von dnsmasq:

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

um zu sagen, dass der Netzwerkmanager DNSMarq verwendet, habe ich außerdem diese Zeile hinzugefügt /etc/NetworkManager/conf.d/dns.conf:

[main]
dns=dnsmasq

Um das erste Problem im NetworkManager zu beheben, habe ich eine spezifischere Route hinzugefügt, die eine höhere Priorität hat als die Standardroute enp3s0:

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

Das ist alles. Der gesamte Datenverkehr zu internen Ressourcen fließt über das VPN, der restliche Datenverkehr fließt wie zuvor.

Außerdem habe ich das Überschreiben von /etc/resolve.conf abgelehnt

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

chattr -i /etc/resolv.conf ((zum Aufheben des Schutzes, Standardmodus)) - zum Zurücksetzen

Hoffe, es ist für jemanden hilfreich.

Answer