Ich habe ein Site-to-Site-VPN mit OpenVPN konfiguriert. Der Tunnel scheint einwandfrei zu funktionieren (und ich kann von einem Ende zum anderen pingen), aber ich kann die Netzwerke an den beiden Enden nicht dazu bringen, sich gegenseitig zu sehen.
Meine Topologie ist wie folgt:
Net1 (192.168.13.0/24)
|
|
|
192.168.13.35
ens160
-----------
OVPN Client
-----------
tun0
10.13.10.2
|
|
10.13.10.1
tun0
-----------
OVPN Server
-----------
ens160
10.1.121.6
|
|
Net2 (10.1.121.0/26)
Ich kann vom Client zum Server pingen:
srv# ping 10.13.10.2
PING 10.13.10.2 (10.13.10.2) 56(84) bytes of data.
64 bytes from 10.13.10.2: icmp_seq=1 ttl=64 time=5.46 ms
64 bytes from 10.13.10.2: icmp_seq=2 ttl=64 time=5.01 ms
Ich gelange vom Client zu Net1 (natürlich nach dem Hinzufügen der entsprechenden Routen):
client#ping 10.1.121.8
PING 10.1.121.8 (10.1.121.8) 56(84) bytes of data.
64 bytes from 10.1.121.8: icmp_seq=1 ttl=63 time=48.0 ms
Der umgekehrte Weg (vom Server aus ein Pingsignal an das Client-Netzwerk -Net2- senden) ist mir jedoch völlig fehlgeschlagen. Ich kann vom Server aus nicht einmal die IP des Clients auf Net2 erreichen:
server#ping 192.168.13.35
PING 192.168.13.35 (192.168.13.35) 56(84) bytes of data.
^C
--- 192.168.13.35 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2014ms
Die passenden Routen habe ich:
server# ip route
default via 10.1.121.1 dev ens160 onlink
10.1.121.0/26 dev ens160 proto kernel scope link src 10.1.121.6
10.13.10.0/24 dev tun0 proto kernel scope link src 10.13.10.1
192.168.13.0/24 via 10.13.10.2 dev tun0
client# ip route
default via 192.168.13.1 dev ens160 onlink
10.1.121.0/24 via 10.13.10.1 dev tun0
10.13.10.0/24 dev tun0 proto kernel scope link src 10.13.10.2
192.168.13.0/24 dev ens160 proto kernel scope link src 192.168.13.35
IPTables blockiert nichts (alles ist auf ACCEPT eingestellt):
client# iptables -L -vn
Chain INPUT (policy ACCEPT 56 packets, 3839 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 40 packets, 4343 bytes)
pkts bytes target prot opt in out source destination
server# iptables -L -vn
Chain INPUT (policy ACCEPT 736 packets, 75398 bytes)
pkts bytes target prot opt in out source destination
2 168 ACCEPT all -- tun0 * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT 4 packets, 236 bytes)
pkts bytes target prot opt in out source destination
1 84 ACCEPT all -- tun0 * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 449 packets, 43393 bytes)
pkts bytes target prot opt in out source destination
Wenn ich einen TCPdump auf der Tunnelschnittstelle ausführe, sehe ich, wie die ICMP-Pakete den Client verlassen, aber nicht, wie sie auf dem Server eingehen:
server# ping 192.168.13.35
PING 192.168.13.35 (192.168.13.35) 56(84) bytes of data.
16:57:40.262004 IP 10.13.10.1 > 192.168.13.35: ICMP echo request, id 1562, seq 1, length 64
16:57:41.269165 IP 10.13.10.1 > 192.168.13.35: ICMP echo request, id 1562, seq 2, length 64
16:57:42.277154 IP 10.13.10.1 > 192.168.13.35: ICMP echo request, id 1562, seq 3, length 64
16:57:43.285163 IP 10.13.10.1 > 192.168.13.35: ICMP echo request, id 1562, seq 4, length 64
client# tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
Beide Endpunkte sind Ubuntu 16.04 Server LTS (x64, größtenteils mit den Standardeinstellungen installiert).
Ich dachte, ich wüsste ein bisschen über Linux-Netzwerke, aber ... anscheinend lag ich falsch :). Ich habe keine Ahnung, warum das nicht funktioniert, und mir gehen die Ideen aus, was ich versuchen könnte. Kann mir bitte jemand den richtigen Weg weisen?
Danke schön!
Antwort1
Möglicherweise fehlt Ihnen das iroute. Zusätzlich zum Pushen von Routen benötigen Sie irouteKonfigurationsdateien. Hier ist der Auszug aus der OpenVPN-Manpage.
--iroute network [Netzmaske]
Erzeugt eine interne Route zu einem bestimmten Client. Der Parameter netmask wird, wenn er weggelassen wird, standardmäßig auf 255.255.255.255 gesetzt. Diese Direktive kann verwendet werden, um ein festes Subnetz vom Server zu einem bestimmten Client zu routen, unabhängig davon, von wo aus sich der Client verbindet. Denken Sie daran, dass Sie die Route auch zur Systemroutingtabelle hinzufügen müssen (beispielsweise mithilfe der Direktive --route). Der Grund, warum zwei Routen benötigt werden, ist, dass die Direktive --route das Paket vom Kernel zu OpenVPN routet. In OpenVPN routet die Direktive --iroute zu dem bestimmten Client. Diese Option muss entweder in einer Konfigurationsdatei der Clientinstanz mithilfe von --client-config-dir angegeben oder dynamisch mithilfe eines --client-connect-Skripts generiert werden. Die Direktive --iroute hat auch eine wichtige Interaktion mit --push "route ...". --iroute definiert im Wesentlichen ein Subnetz, das einem bestimmten Client gehört (wir nennen diesen Client A). Wenn Sie möchten, dass andere Clients das Subnetz von A erreichen können, können Sie --push "route ..." zusammen mit --client-to-client verwenden, um dies zu erreichen. Damit alle Clients das Subnetz von A sehen können, muss OpenVPN diese Route an alle Clients AUSSER A pushen, da das Subnetz bereits A gehört. OpenVPN erreicht dies, indem es eine Route nicht an einen Client pusht, wenn sie mit einer der iroutes des Clients übereinstimmt.
Sie benötigen Konfigurationseinträge wie die folgenden im jeweiligen Client und auf den Servern.
iroute 192.168.3.0 255.255.255.0
Darüber hinaus müssen Sie möglicherweise CCD ausprobieren, wenn Sie mehrere Netzwerke hinter mehreren Clients haben.
Client-Konfigurationsverzeichnis
Diese Anweisung legt ein Client-Konfigurationsverzeichnis fest, das der OpenVPN-Server bei jeder eingehenden Verbindung nach einer clientspezifischen Konfigurationsdatei durchsucht (weitere Informationen finden Sie auf der Handbuchseite). Dateien in diesem Verzeichnis können im laufenden Betrieb aktualisiert werden, ohne dass der Server neu gestartet werden muss. Beachten Sie, dass Änderungen in diesem Verzeichnis nur für neue Verbindungen wirksam werden, nicht für bestehende Verbindungen. Wenn Sie möchten, dass eine clientspezifische Konfigurationsdateiänderung sofort auf einem aktuell verbundenen Client wirksam wird (oder auf einem Client, dessen Verbindung getrennt wurde, dessen Instanzobjekt der Server jedoch nicht abgelaufen ist), beenden Sie das Client-Instanzobjekt mithilfe der Verwaltungsschnittstelle (siehe unten). Dadurch wird der Client erneut verbunden und verwendet die neue Datei „client-config-dir“.
Antwort2
Fossils Antwort war genau das, was ich brauchte, und ich habe sie bereits akzeptiert. Ich möchte nur einige Informationen für andere Leute hinzufügen, die möglicherweise das gleiche Problem haben. Da die Frage bereits zuvor auf Serverfault gestellt wurde, die Antworten jedoch entweder keine Erwähnung von iroute enthalten (ein Beispiel) oder haben nur tote Links (wieDieses hier)
Also... zunächst einmal habe ich eine nette Erklärung zu iroute gefunden (und warum es benötigt wird)Hier. Da ich aber gerade das Risiko toter Links angesprochen habe, werde ich versuchen, im Folgenden auch die wichtigsten Ideen zu erwähnen.
Es sieht so aus, als ob Kernelrouten nicht ausreichen, damit der Datenverkehr durch einen OpenVPN-Tunnel läuft. Wenn Sie ein LAN erreichen möchten, das sich hinter einem OpenVPN-Client befindet, benötigen Sie außerdem eine interne OpenVPN-Route (iroute). Diese wird hinzugefügt, indem Sie eine client-configuration-dir-Anweisung in server.conf verwenden und die iroute-Anweisungen in Konfigurationsdateien in diesem Unterverzeichnis hinzufügen.
In meinem Fall brauchte ich außerdem:
#Inside server.conf
client-configuration-dir my-config-dir
#Inside my-config-dir/client1 (same name as the client!)
#Tell OpenVPN that 192.168.13.0/24 is reachable via client1
iroute 192.168.13.0 255.255.255.0
Dies wirft auch ein interessantes Problem auf: Wenn OpenVPN nicht nur mit Kernel-Routen funktioniert, scheint es auf den ersten Blick unmöglich, ein Routing-Protokoll über den OVPN-Tunneln auszuführen. Hat jemand eine solche Lösung (OVPN+Rip/OSPF) zum Laufen gebracht?