MULTI: schlechte Quelladresse vom Kunden - einmalige Lösungen?

Setup: Ich habe ein OpenVPN-Client / Server-Setup (Konfigurationsdateien unten) und erhalte die berüchtigte MULTI: bad source address from client [192.168.x.x], packet droppedNachricht auf dem Server. Der Server hat eine öffentliche IP-Adresse, während sich der Client hinter NAT befindet.

Mängel zuvor vorgeschlagener Lösungen: Die client-config-dirin der Serverkonfiguration definierte ist derzeit leer. In früheren Beiträgen (hier und in den OpenVPN-Support-Foren) wurde empfohlen, entweder eine Datei DEFAULTmit den richtigen Regeln hinzuzufügen oder eine Datei client-config-dirpro Benutzer mit diesen Regeln hinzuzufügen, um das Problem zu lösen.

Dies scheint jedoch keine langfristige Lösung zu sein, da diese Regeln standortspezifisch sind. Daher kann ich eine Regel hinzufügen, mit der Clients 192.168.x.0eine Verbindung herstellen können. Wenn sie jedoch eine Verbindung von einem anderen Netzwerk herstellen, das stattdessen 192.168.y.0NAT verwendet, ist eine neue Regel erforderlich.

Fragen:

• Können die erforderlichen Regeln generisch / einmalig geschrieben werden?
• Kann jemand erklären, warum dieses Problem überhaupt auftritt?

Serverkonfiguration:

port 1234
proto tcp
dev tun

ca ca.crt
cert openvpn.crt
key openvpn.key
dh dh2048.pem

server 10.78.96.0 255.255.255.0
keepalive 10 120
comp-lzo
cipher CAMELLIA-128-CBC

user nobody
group nogroup  
persist-key
persist-tun
client-cert-not-required
plugin /usr/lib/openvpn/openvpn-auth-pam.so login

status openvpn-status.log

push "redirect-gateway def1"
push "remote-gateway 1.2.3.4"
push "dhcp-option DNS 8.8.8.8"

client-config-dir ccd
verb 4

Client-Konfiguration:

ca ca.crt
client
dev tun
proto tcp
remote 1.2.3.4 1234

auth-user-pass
script-security 2
keepalive 5 60
topology subnet
resolv-retry infinite
nobind
persist-key
persist-tun
ns-cert-type server
cipher CAMELLIA-128-CBC
comp-lzo
verb 4

Sie fragten: " Kann jemand erklären, warum dieses Problem überhaupt auftritt? "

Basierend auf den offiziellen OpenVPN-FAQs wette ich, dass dies auf ein Routing-Problem in der OpenVPN-Engine zurückzuführen ist.

Lassen Sie mich zur besseren Verdeutlichung des Szenarios auf das folgende Diagramm verweisen:

Hier sieht man:

• ein OpenVPN "Server", der mit dem internen HEADQUARTER-Netzwerk verbunden ist (10.0.1.0/24)
• Ein OpenVPN- "Client", der an einem Remote-Standort ausgeführt und mit dem Remote-Netzwerk 192.168.1.0/24 verbunden wird

Ebenfalls

• Wir gehen davon aus, dass der OpenVPN-Tunnel eingerichtet ist und:
  • OpenVPN "Server" ist über eine eigene Tun- Schnittstelle mit der Adresse 10.10.0.1 erreichbar. Auch die P2P-Adresse, die von der Tun-Schnittstelle verwendet wird, ist 10.10.0.2 ( dies ist wichtig für spätere Diskussionen, also lasst es uns hervorheben ).
  • OpenVPN "Client" hat eine Tun- Schnittstelle mit IP 10.10.0.2

Nehmen wir nun an, dass:

• Der OpenVPN "Client" hat sein Standard-Gateway neu definiert, um den gesamten ausgehenden IP-Verkehr innerhalb des Tunnels umzuleiten.
• Der OpenVPN "Client" hat IP_FORWARDING aktiviert und kann als solches Pakete aus seinem internen LAN (192.168.1.0/24) weiterleiten ( ich betone diesen Punkt, da er für unsere Diskussion von entscheidender Bedeutung ist ).

Lassen Sie uns in einem solchen Szenario im Detail prüfen, was passiert, wenn R_PC1 (192.168.1.2) ein Paket wie eine Echoanforderung an L_PC1 (10.0.1.2) sendet:

1. Nach dem Verlassen der R_PC1-Netzwerkkarte erreicht das Paket den OpenVPN-Client.
2. Der OpenVPN-Client (der als gemeinsamer Router konfiguriert ist) leitet ihn gemäß seiner Routing-Tabelle weiter. Da das Standard-Gateway der Tunnel ist, sendet es das Paket an den Tunnel.
3. Das Paket erreicht die Tun-Schnittstelle des OpenVPN-Servers. OpenVPN "sieht" es und "leitet" das Paket von TUN an LAN weiter, da es (OpenVPN-Server) weiß, dass 10.0.1.2 eine Adresse ist, die zu seinem LAN-Subnetz gehört.
4. Paket erreichen L_PC1.

Also ist alles in Ordnung ...

Lassen Sie uns nun überprüfen, was mit der Echoantwort passiert, die L_PC1 auf R_PC1 antwortet.

5. Die Echo-Antwort verlässt die L_PC1-Netzwerkkarte und erreicht die LAN-Schnittstelle des OpenVPN-Servers (10.0.1.1).

Wenn OpenVPN Server nun den Remote-Standort erreichen soll, müssen wir das Routing mit einer "statischen Route" definieren. Etwas wie:

route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.10.0.2

Bitte beachten Sie die als Gateway verwendete P2P-Adresse .

Solche statischen Routen werden auf Betriebssystemebene ausgeführt. Mit anderen Worten, das Betriebssystem muss das Paket ordnungsgemäß weiterleiten. Es bedeutet ungefähr: "Bitte, der gesamte an das Subnetz 192.168.1.0/24 adressierte Datenverkehr muss an die OpenVPN-Engine weitergeleitet werden, mit der das Betriebssystem über die P2P-Adresse kommunizieren kann." Dank dieser statischen Route jetzt ...

6. Das Paket verlässt den OS-Routing-Kontext und erreicht OpenVPN. Die OpenVPN-Instanz, die auf dem OpenVPN-Server ausgeführt wird. Zu diesem Zeitpunkt hat das Betriebssystem also nichts mehr zu tun und das gesamte Routing (innerhalb des VPN) bleibt der OpenVPN-Serversoftware überlassen.

Das Problem ist nun: Wie kann die openvpn-Serversoftware mit SRC_IP 10.0.1.2 und DST_IP 192.168.1.2 die Route eines Pakets bestimmen ?

Bitte beachten Sie, dass basierend auf der Konfiguration des OpenVPN-Servers nichts über das Netzwerk 192.168.1.0/24 oder den Host 192.168.1.2 bekannt ist. Es ist kein verbundener Client. Es ist kein lokaler Kunde. Und so? OpenVPN weiß auch, dass es nicht der "OS-Router" ist, also will (und kann ...) das Paket nicht wirklich an das lokale Gateway zurücksenden. Die einzige Möglichkeit besteht hier darin, einen Fehler auszulösen. Genau der Fehler, den Sie haben

Um es mit der Sprache der FAQ zu sagen: " ... es weiß nicht, wie das Paket an diesen Computer weitergeleitet werden soll, also lässt es das Paket fallen ... ".

Wie können wir das Problem lösen?

Wie Sie der offiziellen Dokumentation entnehmen können , entspricht die Option iroute genau unserem Anwendungsbereich:

--iroute network [netmask]
Generate an internal route to a specific client. The netmask 
parameter, if omitted, defaults to 255.255.255.255.
This directive can be used to route a fixed subnet from the server 
to a particular client, regardless of where the client is 
connecting from. Remember that you must also add the route to the 
system routing table as well (such as by using the --route 
directive). The reason why two routes are needed is that the 
--route directive routes the packet from the kernel to OpenVPN. 
Once in OpenVPN, the --iroute directive routes to the specific 
client.

Also brauchst du ein:

--iroute 192.168.1.0 255.255.255.0

Wird angewendet (auf den Server), wenn Ihr OpenVPN-Client eine Verbindung herstellt, z. B. über eine auf dem Server definierte Ad-hoc-Konfigurationsdatei (Client-Konfigurationsverzeichnis usw.).

Sollten Sie sich fragen , warum dieses Problem nicht nicht in Schritt passiert 2) oben, mein Verständnis ist , dass OpenVPN - Client weiß , wie man Weg ist es, weil es weiß , dass der VPN-Tunnel ist ein Standard-Gateway.

Dies ist bei OpenVPN Server nicht möglich, da dort das Standard-Gateway normalerweise nicht überschrieben wird. Bedenken Sie auch, dass Sie einen einzelnen OpenVPN-Server mit vielen OpenVPN-Clients haben könnten: Jeder Client weiß, wie er den Server erreicht, aber ... wie kann der Server entscheiden, welcher Client als Gateway für ein unbekanntes Subnetz fungiert?

Was Ihre erste Frage betrifft ( Können die erforderlichen Regeln generisch / einmalig geschrieben werden? ), Tut mir leid, aber ich bekomme nicht genau Ihr Problem. Können Sie weitere Details umformulieren?

Ich hatte ein ähnliches Problem, bin mir aber nicht sicher, ob es mit Ihrem Problem identisch ist. Ich habe versucht, von einem openvpn-Client zu einem Computer im lokalen Netzwerk des openvpn-Servers zu pingen (in der Konfiguration des Servers geroutet), habe keine Antwort erhalten und konnte die Meldung "Ungültige Quelladresse" im openvpn-Protokoll des Servers sehen.

Um es zu lösen, musste ich zwei Dinge tun:

1. Aktivieren Sie die IP-Weiterleitung auf dem Server.
2. Fügen Sie eine Route für das VPN-Subnetz im Gateway des Servers hinzu, da das Gateway für das lokale Netzwerk des Servers in meinem Fall nicht der Server selbst ist, sondern ein Router. Der Ping-Computer versuchte, über das Gateway zu antworten, das keine Ahnung hatte, was er für das VPN-Subnetz tun sollte. Also habe ich dem Router eine statische Route hinzugefügt, die das VPN-Subnetz als Ziel verwendet, und die IP des OpenVPN-Servers als Gateway dafür.

Das hat es für mich behoben.