☰

Маршрутизация VPN-мультисайтов

tag-icon • tag-icon linux networking iptables linux-networking ipsec
Маршрутизация VPN-мультисайтов

В настоящее время я настраиваю многосайтовую (3 сайта) VPN.

Вот быстрый рисунок:

введите описание изображения здесь

Пока что настройка в порядке и работает так, как и ожидалось. Пинг 10.10.20.1 <-> 10.10.10.1, а также 10.10.30.1 <-> 10.10.10.1 работает нормально.

Теперь я хочу выяснить, как подключиться из 10.10.20.1 в 10.10.30.1.

Я думаю, что мне нужно использовать iptablesдля этого, это правильно?

Если кто-то сможет объяснить, какие шаги необходимы и почему, это мне очень поможет!

решение1

Не делайте NAT. NAT — это халтура, которую следует избегать везде, где это возможно. Она нарушает принцип end-to-end, используемый в качестве основы TCP/IP.

При использовании статических маршрутов вам необходимо направить их в туннель. Если маршрутизаторы обмениваются информацией о маршрутизации (OSPF, ...), маршруты должны подниматься автоматически. Для поднятия туннелей могут потребоваться статические маршруты (динамическая маршрутизация обновляется только после поднятия туннеля).

решение2

Я разобрался. Вот мое длинное и быстрое решение:

долгое (не совсем) решение

На нижнем сервере:

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

На верхнем левом сервере:

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

На верхнем правом сервере:

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

Хотя маршрутизация работает, strongswan запрещает соединения, как показал tcpdump.

[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

быстрое решение

Это решение довольно удобное, поскольку strongswan/ipsec управляет всеми iptable и статическими маршрутами, а также разрешает доступ к указанным подсетям.

На нижнем сервере:

# /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
    ...

На верхнем левом сервере:

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

На верхнем правом сервере:

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

Вот как должен выглядеть успешный tcpdumped ping:

[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

Связанный контент