На изображении выше показано, что, по моему мнению, происходит во время соединения OpenVPN. Хосты A и B подключены к VPN через VPN-сервер 1.2.3.4:1194. Мой вопрос: если хост A желает отправить пакет на хост B (скажем, эхо-пакет ICMP), как пакет проходит, чтобы добраться до B? Мои первоначальные мысли были:
Процесс создает пакет с местом назначения 10.20.0.6 и источником 192.168.0.x (IP-адрес источника 192.168.0.x, учитывая, что приложение не знает о VPN-соединении). Из таблиц маршрутизации, переданных на компьютер приложения, пакет отправляется на виртуальный интерфейс.
Виртуальный интерфейс хоста A инкапсулирует пакет, предназначенный для WAN-адреса хоста B (3.4.5.6).
Это пока правильно? Как маршрутизатор в B знает, что этот пакет предназначен для хоста B? Вместо этого хост A устанавливает 1.2.3.4 в качестве пункта назначения (а не 3.4.5.6) и позволяет серверу VPN перенаправлять маршрут через уже установленное соединение сервера с B? Нужно ли предварительно настроить маршрутизатор в точке B, чтобы разрешить какое-либо соединение VPN?
Предположим, у вас все уже настроено, и вы выпускаете
$ ping 10.20.0.6
на ведущей А.
Хост A проверяет свою внутреннюю таблицу маршрутизации, чтобы увидеть, как он может достичь 10.20.0.6, в Linux это будет примерно так
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.20.0.0 10.20.0.1 255.255.255.0 UG 0 0 0 tun0
Итак, хост A определяет: «Чтобы связаться с 10.20.0.6, мне нужно отправить свое сообщение через шлюз 10.20.0.1, с которым я могу связаться с помощью tun0 интерфейс"
10.20.0.1 - это VPN-адрес сервера OpenVPN и tun0 - это программно определяемый сетевой интерфейс, созданный клиентской программой OpenVPN на хосте A.
Таким образом, хост A отправляет эхо-запрос ICMP с адресом назначения 10.20.0.6 на адрес tun0. Что тогда происходит? Инкапсуляция. Клиент OpenVPN оборачивает исходный пакет в конверт OpenVPN и отправляет этот конверт на 1.2.3.4:1194.
Сервер OpenVPN в 1.2.3.4 открывает конверт и проверяет адрес: «О, это для 10.20.0.6». Если сервер OpenVPN настроен так, чтобы клиенты могли разговаривать друг с другом, он затем отправит конверт через установленное соединение с B по адресу 3.4.5.6.
Клиент OpenVPN в точке B открывает полученный конверт (Деинкапсуляция) и теперь имеет эхо-запрос ICMP для 10.20.0.6, полученный с адреса 10.20.0.5, который является хостом A в сети VPN.
Для работы OpenVPN требуется только TCP или UDP-соединение с портом 1194 на сервере. Если брандмауэр или неправильно настроенный NAT предотвращают это, это не сработает.