Назад | Перейти на главную страницу

Понимание реализации VPN

На изображении выше показано, что, по моему мнению, происходит во время соединения 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 предотвращают это, это не сработает.