Шлюз без NAT через OpenVPN

у меня несколько серверов (B, C,...) которые находятся в одном месте и одна машина (а), которая находится за обычным старым домашним маршрутизатором. Я хочу, чтобы все они смогли соединиться друг с другом. Мне кажется, что OpenVPN-отличное место для начала, поэтому я создал туннель (tun0) между A и B через интернет. Вот так выглядит ситуация:

 10.8.0.4                 10.8.0.1
----------  10.8.0.0/24   ---------- 
|        |                |        | 
|   A   tun0 ----------- tun0  B   | 10.128.140.204 
|        |                |        | 
----------                -- eth1 -- 
                              |
                              | 10.128.0.0/16
                              |
                          -- eth1 --
                          |        |
                          |    C   | 10.128.13.224
                          |        |
                          ----------

в частности, мне нужно, чтобы иметь возможность достичь C по адресу 10.128.13.224 и C, чтобы иметь возможность достичь под адрес 10.8.0.4. Это означает, что NAT не будет делать - большинство ресурсов говорят о настройке NAT на B, чтобы A мог видеть C - и вот где это кажется сложным.

так вот что я пытался сделать сейчас:

  • скажите A использовать 10.8.0.1 как шлюз для 10.128.0.0 / 16
  • скажите B использовать 10.128.140.204 в качестве шлюза для 10.8.0.0 / 24
  • попробуй в качестве шлюза

таблица маршрутизации на:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         [home router]   0.0.0.0         UG    0      0        0 enp0s3
10.8.0.0        *               255.255.255.0   U     0      0        0 tun0
10.128.0.0      localhost       255.255.0.0     UG    0      0        0 tun0
[home ip]       *               255.255.255.0   U     0      0        0 enp0s3

A# ip route get 10.128.13.224
10.128.13.224 via 10.8.0.1 dev tun0  src 10.8.0.4
    cache

выглядит большой. Таблица маршрутизации на C:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         gateway         0.0.0.0         UG    0      0        0 eth0
10.8.0.0        10.128.140.204  255.255.255.0   UG    0      0        0 eth1
10.13.0.0       *               255.255.0.0     U     0      0        0 eth0
10.128.0.0      *               255.255.0.0     U     0      0        0 eth1
[public IP]     *               255.255.255.0   U     0      0        0 eth0

C# ip route get 10.8.0.4
10.8.0.4 via 10.128.140.204 dev eth1  src 10.128.13.224
    cache

большой. Включить переадресацию IP на B:

B# cat /proc/sys/net/ipv4/ip_forward
1

Я думаю, по умолчанию принять все правила в iptables также будут работать, но для хорошей меры, я ограничил для прямой цепи немного:

B# iptables -S
-P INPUT ACCEPT
-P FORWARD DROP
-P OUTPUT ACCEPT
-A FORWARD -s 10.128.0.0/16 -d 10.8.0.0/24 -i eth1 -o tun0 -j ACCEPT
-A FORWARD -s 10.8.0.0/24 -d 10.128.0.0/16 -i tun0 -o eth1 -j ACCEPT

Ну, они этого не делают. A# ping 10.128.41.180 ничего и C# ping 10.8.0.4.

если я добавляю NAT следующим образом:

B# iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -s 10.8.0.0/24 -d 10.128.0.0/16 -o eth1 -j MASQUERADE

затем пинг от A до C завод.

A# ping 10.128.13.224
PING 10.128.13.224 (10.128.13.224) 56(84) bytes of data.
64 bytes from 10.128.13.224: icmp_seq=1 ttl=63 time=120 ms
...

это не то, что я хочу сделать, но я думаю, это означает, что что-то работает. Еще одна любопытная вещь заключается в том, что если я настроить маскарад наоборот, пинг от C до A делает не работа, так что я думаю, здесь может быть подсказка.

теперь я начинаю задаваться вопросом, если то, что я хочу сделать, даже может быть сделано, или если у меня есть некоторые основные непонимание того, как работает сеть. Разве такое вообще возможно? Я не замечаю что-то простое? Я был бы признателен за любые намеки или ресурсы.

5
задан Tillerino
04.03.2023 5:42 Количество просмотров материала 2877
Распечатать страницу

1 ответ

оказывается, что выше будет работать красиво в обычной обстановке. Сервера (B,C, ...) однако находились в сети, которая не позволяет отправлять пакеты, адрес источника которых не совпадает с IP адресом отправителя:

, когда отображается C С A,A посылает IP-пакет внутри Ethernet-кадра через tun0 to B, который примерно выглядит так:

----------------------------------------------------
| source: A's tun0 MAC | destination: B's tun0 MAC |
| -------------------------------------------------|
| | source: 10.8.0.4 | destination: 10.128.13.224 ||
| | payload: PING                                 ||
| -------------------------------------------------|
----------------------------------------------------

B затем проверяет свою маршрутизацию и отправляет следующее над eth1:

----------------------------------------------------
| source: B's eth1 MAC | destination: C's eth1 MAC |
| -------------------------------------------------|
| | source: 10.8.0.4 | destination: 10.128.13.224 ||
| | payload: PING                                 ||
| -------------------------------------------------|
----------------------------------------------------

сеть проверяет это и находит, что адрес источника 10.8.0.4 не соответствует B's eth1 адрес 10.128.140.204 и не передает кадр. Вот почему простой шлюз не будет работать в этой сети.

1
отвечен Tillerino 2023-03-05 13:30

Постоянная ссылка на данную страницу: [ Скопировать ссылку | Сгенерировать QR-код ]

Ваш ответ

Опубликуйте как Гость или авторизуйтесь

Имя
Вверх