Ich habe einen Server A mit einem VPN, das zu einem anderen Server B konfiguriert ist. Derzeit kann Server A Server B über die VPN-Adresse anpingen 10.12.0.1.
Ich möchte den gesamten HTTPS-Verkehr über Server B leiten und den übrigen Verkehr die Standardschnittstelle verwenden lassen.
Dazu habe ich mich inspirieren lassen vondiese Unix Stackexchange-Antwortund habe die folgenden Befehle ausgeführt:
# define route
echo "200 myroute" >> /etc/iproute2/rt_tables
# seems necessary
sysctl -w net.ipv4.conf.wg1.rp_filter=2
# actual routing
ip route add table 200 10.12.0.0/24 dev wg1 src 10.12.0.10
ip route add table 200 default via 10.12.0.1
# actual rule telling HTTPS traffic to use table 200
ip rule add iif lo ipproto tcp dport 443 lookup 200
Dann führe ich curl https://1.1.1.1(oder einen anderen Host) aus und erhalte den Fehler Failed to connect to 1.1.1.1 port 443: No route to host. Wenn ich die Regel entferne, funktioniert alles wieder.
Ich vermute, dass mein Routing für Tabelle 200 nicht korrekt ist, aber es scheint mit dem aus der ursprünglichen Antwort und denen für die Standardschnittstelle übereinzustimmen.
Wissen Sie, wie ich das Problem untersuchen und beheben kann?
Danke
Zusatzinformationen:
$ ip route show table 200
default via 10.12.0.1 dev wg1
10.12.0.0/24 dev wg1 scope link src 10.12.0.10
$ ip route show dev wg1
10.12.0.0/24 proto kernel scope link src 10.12.0.10
$ ip route get 1.1.1.1 ipproto tcp dport 443
1.1.1.1 via 10.12.0.1 dev wg1 table 200 src 10.12.0.10 uid 1001
cache
$ ip route
default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.51 metric 202
10.12.0.0/24 dev wg1 proto kernel scope link src 10.12.0.10
192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.51 metric 202
Das VPN ist ein Wireguard-VPN. Wenn der gesamte Datenverkehr über das VPN geleitet wird, funktioniert alles.
Antwort1
Der Fehler „Keine Route zum Host“ ist wahrscheinlich auf den Versuch zurückzuführen, eine Verbindung zu einem Host ( 1.1.1.1) herzustellen, der nicht in Ihren WireGuard- AllowedIPsEinstellungen enthalten ist. Vorausgesetzt, Sie verwenden wg-quick, gehen Sie wie folgt vor:
AlsSchritt 1Passen Sie in der WireGuard-Konfiguration von Server A die AllowedIPsEinstellung im [Peer]Abschnitt für Server B an, um die IP-Adressen (oder IP-Adressblöcke) einzuschließen, mit denen Sie eine Verbindung herstellen möchten.
Angenommen 1.1.1.1, Sie möchten von Server A aus eine Verbindung zu jedem HTTPS-Server im Block herstellen können 192.0.2.0/24(und insbesondere gab es einen Server, 192.0.2.123mit dem Sie testen). Nehmen wir außerdem an, Sie haben Ihre Einstellung zunächst auf Server A so eingerichtet, AllowedIPsdass Server B den Block enthält 10.12.0.0/24. Ändern Sie diese Einstellung wie folgt:
AllowedIPs = 10.12.0.0/24, 192.0.2.0/24
Entfernen Sie die Routen und Regeln, die Sie zuvor für Tabelle 200 auf Server A festgelegt haben, starten Sie WireGuard neu (z. B. sudo wg-quick down wg1; sudo wg-quick up wg1) und testen Sie diese Änderung, indem Sie Folgendes ausführen:
$ curl -k https://192.0.2.123
Damit sollten Sie zumindest den Fehler „Keine Route zum Host“ überwinden können. Wenn Sie nur deswegen immer noch Fehler erhalten, müssen Sie wahrscheinlich Ihre Firewall-/Routing-Regeln auf Server B anpassen, damit Pakete von Server A an weitergeleitet werden können 192.0.2.0/24.
AlsSchritt 2Fügen Sie im [Interface]Abschnitt der WireGuard-Konfiguration von Server A die folgende Einstellung hinzu:
Table = 200
Dadurch wird wg-quick angewiesen, die Routen, die es automatisch für Sie erstellt, zu Ihrer benutzerdefinierten 200Routing-Tabelle hinzuzufügen, anstatt zu Ihrer Haupttabelle. Starten Sie WireGuard erneut und überprüfen Sie Ihre Routing-Tabellen:
$ ip route
default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.51 metric 202
192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.51 metric 202
$ ip route show table 200
10.12.0.0/24 dev wg1 scope link
192.0.2.0/24 dev wg1 scope link
Fügen Sie nun Ihre spezielle HTTPS-Richtlinienregel hinzu:
$ sudo ip rule add iif lo ipproto tcp dport 443 lookup 200
Und testen Sie es:
$ curl -k https://192.0.2.123
AlsSchritt 3Vorausgesetzt, Sie möchten für andere Dienste als HTTPS (wie SSH usw.) weiterhin eine direkte Verbindung von Server A zu Server B über WireGuard herstellen können, fügen Sie auf Server A eine weitere Richtlinienregel für alle Verbindungen zum 10.12.0.0/24Block hinzu:
$ sudo ip rule add to 10.12.0.0/24 table 200 priority 201
Jetzt sollten Sie WireGuard verwenden können, um wieder eine Verbindung von Server A zu Server B herzustellen:
$ ssh 10.12.0.1