Ich betreibe ein Backend auf der DO-Infrastruktur, nenne es SiteYvi, die eine Verbindung zu einer Website eines Drittanbieters herstelltProvüber einen IPsec-Tunnel mit dieser Libreswan-Konfiguration:
conn prov-client
...
right=$YVI_IP
rightsourceip=10.31.3.1
rightsubnet=10.31.3.0/28
left=$PROV_IP
leftsubnet=10.70.0.36/28
Provhat einen Server auf dem läuft 10.70.0.37, und ich kann mit ihm interagieren vonYvi.
Mein Problem ist, dass ich eine lokale Entwicklungsumgebung einrichte (eine Ubuntu-Box in einem anderen Netzwerk) und jedes Mal, wenn ich eine Änderung vornehme, muss ich sie inYvidenn nur von dort aus kann ich die API erreichen inProv. Ich möchte dies vermeiden, indem ich eine Verbindung herstelleLokalZuYviund leiten Sie den Verkehr weiter anProvum die API erreichen zu können inProvausLokalund die Entwicklung zu erleichtern.
Ich verbindeLokalZuYvials Road Warrior mit folgender Konf:
conn remote-dev-client
...
left=$YVI_IP
leftsubnet=10.31.3.0/28
right=%any
rightaddresspool=10.31.4.1-10.31.4.254
Die Verbindung wurde erfolgreich hergestellt und vonLokal10.31.3.1Ich erreicheYvi. Ich möchte erreichen 10.70.0.37inProvausLokal. Die Route zum 10.70.0.36/28Netzwerk wird nicht automatisch hinzugefügt, also habe ich versucht, einige ip xfrmRegeln ip routemanuell festzulegenLokal:
# Outgoing
ip xfrm policy add dst 10.70.0.37 src 10.31.4.1 dir out tmpl src $LOCAL_IP dst $YVI_IP proto esp spi $SPI reqid $REQID mode tunnel priority 100000
# Incoming
ip xfrm policy add dst 10.31.4.1 src 10.70.0.37 dir fwd tmpl src $YVI_IP dst $LOCAL_IP proto esp reqid $REQID mode tunnel priority 100000
ip xfrm policy add dst 10.31.4.1 src 10.70.0.37 dir in tmpl src $YVI_IP dst $LOCAL_IP proto esp reqid $REQID mode tunnel priority 100000
ip route add table 220 src 10.31.4.1 10.70.0.37 via $LOCAL_IP dev $LOCAL_IF proto static
Ich laufe jetzt ip xfrm monitorweiterYviund dann vonLokalPing 10.70.0.37; ich kann die Pakete sehen, die ankommen beiYvi(vom xfrm-Monitor inYvi), aber nur die ausgehende, nicht die Antwort (wie man sieht, wenn ich zum Beispiel 10.31.3.1 pinge), was darauf hindeutet, dassYviempfängt den Datenverkehr, leitet ihn aber nicht weiter anProv? Ich weiß wirklich nicht, wie ich das interpretieren soll.
Ich glaube, ich muss Routen hinzufügen inYvium den Verkehr umzuleiten an dieProvAPI richtig, aber das Hinzufügen ähnlicher Regeln zu den oben genannten hat nicht funktioniert. Ich wäre dankbar für Hilfe, um herauszufinden, was ich übersehe und was ich falsch mache.
Vorschläge für einen anderen Ansatz sind ebenfalls willkommen, obwohl die einzige Möglichkeit, eine Verbindung herzustellen zuProv, die ich nicht kontrolliere, erfolgt über einen IPsec-Tunnel vonYvi, die ich kontrolliere.
Antwort1
Ich konnte das Problem mit iptables NAT-Regeln lösen. Die ip xfrmRichtlinien waren nicht notwendig. Hier ist eine kurze Erklärung meines Vorgehens für jemanden, der wie ich kein Experte ist:
AusYviIch weise den Außendienstmitarbeitern ein 10.31.4.0/24Subnetz zu, sodass eine Route für dieses Netzwerk automatisch vom Keying-Daemon (in meinem Fall Libreswan) installiert wird. Daher habe ich NAT-Regeln hinzugefügt inYvi( /etc/ufw/before.rules, da ich UFW verwende, aber Sie können dasselbe auch iptablesdirekt mit erreichen):
*nat
-F
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
# PRE
-A PREROUTING -s 10.31.4.0/24 -d 10.31.3.2 -j DNAT --to-destination 10.70.0.37
# POST
-A POSTROUTING -s 10.31.4.0/24 -d 10.70.0.37 -j SNAT --to-source 10.31.3.1
COMMIT
Das *natweist iptables an, die Regeln auf die NAT-Tabelle anzuwenden und COMMITspeichert die Regeln tatsächlich. Das -Fdient nur der Bequemlichkeit, da UFW die Regeln hinzufügt, ufw enablesie aber nicht löscht, ufw disablesodass Sie am Ende Duplikate haben, daher das Flush-Flag -F.
Die PREROUTINGRegel gilt für Pakete, die aus dem Road Warrior-Subnetz ankommen 10.31.3.2und für bestimmt sind. Sie ändert die Zieladresse von in in , 10.70.0.37wodurch 10.31.3.2diese IP-Adresse effektiv demProvServer aus der Sicht der Vielreisenden.
Die POSTROUTINGRegel gilt für Pakete, die aus dem Road Warrior-Subnetz kommen und gerade nach draußen gehen 10.70.0.37(also Pakete, die gerade die Prerouting-Regel treffen) und ändert ihre Zieladresse von einer Adresse in 10.31.4.0/0nach 10.31.3.1. Das ist notwendig, weil ich die Routen, Server oder irgendetwas in nicht kontrolliere.Prov, also wennProveine Anfrage aus dem 10.30.4.0/24Subnetz erhält, weiß es nicht, wie es antworten soll. Aber es weiß es 10.31.3.1.
Und das ist es! Jetzt kann ich erreichenProvausLokalüberYvibei 10.31.3.2.