☰

VPN-Multisite-Routing

tag-icon • tag-icon linux networking iptables linux-networking ipsec
VPN-Multisite-Routing

Ich richte derzeit ein Multisite-VPN (3 Sites) ein.

Hier ist eine schnelle Zeichnung:

Bildbeschreibung hier eingeben

Bisher ist das Setup in Ordnung und funktioniert wie erwartet. Das Pingen von 10.10.20.1 <-> 10.10.10.1 sowie 10.10.30.1 <-> 10.10.10.1 funktioniert einwandfrei.

Jetzt möchte ich herausfinden, wie ich eine Verbindung von 10.10.20.1 zu 10.10.30.1 herstelle.

Ich glaube, ich muss iptablesdazu verwenden, ist das richtig?

Es wäre mir eine große Hilfe, wenn mir jemand erklären könnte, welche Schritte notwendig sind und warum!

Antwort1

Kein NAT. NAT ist ein Kludge, der nach Möglichkeit vermieden werden sollte. Es unterbricht das End-to-End-Prinzip, das als Grundlage von TCP/IP verwendet wird.

Bei statischen Routen müssen Sie diese in den Tunnel leiten. Wenn die Router Routing-Informationen austauschen (OSPF, ...), sollten die Routen automatisch aufgebaut werden. Um die Tunnel aufzubauen, können statische Routen erforderlich sein (dynamisches Routing wird erst aktualisiert, wenn der Tunnel aufgebaut ist).

Antwort2

Ich habe es herausgefunden. Hier ist meine lange und schnelle Lösung:

lange (nicht ganz) Lösung

Auf dem unteren Server:

iptables -A FORWARD -s 10.10.30.0/24 -d 10.10.20.0/24 -i enp2s0 -m policy --dir in --pol ipsec --reqid 2 --proto esp -j ACCEPT
iptables -A FORWARD -s 10.10.20.0/24 -d 10.10.30.0/24 -o enp2s0 -m policy --dir out --pol ipsec --reqid 2 --proto esp -j ACCEPT
iptables -A FORWARD -s 10.10.20.0/24 -d 10.10.30.0/24 -i enp2s0 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT
iptables -A FORWARD -s 10.10.30.0/24 -d 10.10.20.0/24 -o enp2s0 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT

Auf dem Server oben links:

ip route add 10.10.30.0/24 via 138.x.x.1 dev eth0 proto static src 10.10.20.1 table 220
iptables -A FORWARD -s 10.10.30.0/24 -d 10.10.20.0/24 -i eth0 -m . policy --dir in --pol ipsec --reqid 2 --proto esp -j ACCEPT
iptables -A FORWARD -s 10.10.20.0/24 -d 10.10.30.0/24 -o eth0 -m policy --dir out --pol ipsec --reqid 2 --proto esp -j ACCEPT

Auf dem Server oben rechts:

ip route add 10.10.20.0/24 via 108.x.x.1 dev eth0 proto static src 10.10.30.1 table 220
iptables -A FORWARD -s 10.10.20.0/24 -d 10.10.30.0/24 -i eth0 -m policy --dir in --pol ipsec --reqid 2 --proto esp -j ACCEPT
iptables -A FORWARD -s 10.10.30.0/24 -d 10.10.20.0/24 -o eth0 -m policy --dir out --pol ipsec --reqid 2 --proto esp -j ACCEPT

Obwohl es hinsichtlich des Routings funktioniert, verbietet Strongswan Verbindungen, wie ein TCPdump gezeigt hat.

[bottom]$ tcpdump -nni enp2s0 icmp
15:35:22.512437 IP 109.x.x.x > 85.x.x.x: ICMP host 109.x.x.x unreachable - admin prohibited, length 48

schnelle Lösung

Diese Lösung ist ziemlich praktisch, da strongswan/ipsec alle iptable- und statischen Routen für Sie verwaltet und auch den Zugriff auf die angegebenen Subnetze ermöglicht.

Auf dem unteren Server:

# /etc/ipsec.conf
conn top-left-to-bottom
    ...
    leftsubnet=10.10.10.0/24,10.10.30.0/24
    ...

conn top-right-to-bottom
    ...
    leftsubnet=10.10.10.0/24,10.10.20.0/24
    ...

Auf dem Server oben links:

# /etc/ipsec.conf
conn top-left-to-bottom
    ...
    rightsubnet=10.10.10.0/24,10.10.30.0/24
    ...

Auf dem Server oben rechts:

# /etc/ipsec.conf
conn top-right-to-bottom
    ...
    rightsubnet=10.10.10.0/24,10.10.20.0/24
    ...

So sollte ein erfolgreicher TCP-Dumping aussehen:

[bottom]$ tcpdump -nni enp2s0 icmp
15:52:37.160859 IP 10.10.20.1 > 10.10.30.1: ICMP echo request, id 1296, seq 1, length 64
15:52:37.164971 IP 10.10.30.1 > 10.10.20.1: ICMP echo reply, id 1296, seq 1, length 64

verwandte Informationen