​​Из пункта A в пункт Б

Как показывает практика – маршрутизация всегда была непростым вопросом, особенно если речь идет о маршрутизации между сетями. И чаще всего бывает так – я все сделал по инструкции, но ничего не работает.

Как быть, что делать, куда бежать? А бежать никуда не надо, надо просто взять в руки два простых инструмента и заняться диагностикой. Эти инструменты всем известны: пинг и трассировка.

Но прежде посмотрим на схему внизу материала. Где:

🔹 A и F – конечные устройства в разных сетях
🔹 B и E – внутренние интерфейсы VPN-серверов (роутеры)
🔹 С и D – стороны туннеля
🔹 X и Y – внешние адреса серверов

Итак, наша задача попасть из пункта A в пункт F и для начала мы посмотрим, как должна выглядеть правильная трассировка. Нам должны ответить по очереди следующие узлы:

1️⃣ B

2️⃣ D

3️⃣ F

И никакие другие. Почему? Потому что пакет по дороге совершает три прыжка: от компьютера-источника A на VPN-сервер B, с него на противоположный конец туннеля – D и оттуда в пункт назначения F, интерфейсы С и E в передаче пакета не участвуют (точнее используются только как интерфейсы выхода).

Если у вас в трассировке появились другие узлы – следовательно вы неправильно настроили маршрутизацию.

Теперь начнем диагностику. Если наша трассировка не доходит даже до первого промежуточного узла B, то берем ping и проверяем его доступность. Если он недоступен – то тут все понятно.

Но может ли быть так, что узел B пингуется, а трассировка не проходит? Может, в том случае, если VPN-сервер не является основным шлюзом сети и это означает что у вас не работает локальная маршрутизация.

В этом случае следует прописать маршрут к удаленной сети через узел B либо непосредственно на узле А, либо на основном шлюзе сети.

Здесь разобрались, идем дальше. Если у нас недоступен следующий узел трассировки – D, то это означает что пакет не удалось отправить на другую сторону туннеля.

В этом случае проверяем доступность (пингом) узла C, что покажет нам поднят ли туннельный интерфейс и отвечает ли он на наши запросы.

Если интерфейс поднят, но не отвечает на пинг, то проверяем включена ли маршрутизация на VPN-сервере и не блокирует ли данные соединения брандмауэр.

Интерфейс поднят и отвечает. Отлично. Теперь самое время разобраться в типе нашего VPN-подключения. Соединения на основе PPP, OpenVPN или AnyConnect строятся по клиент-серверной схеме.

Если с вашей стороны клиент, то доступность туннельного интерфейса означает что туннель поднят и работает, за редкими исключениями. Например, в OpenVPN при неправильно выставленных настройках сжатия туннель поднимается, но не работает.

Поэтом пробуем пропинговать точку D непосредственно с сервера. Если пинг проходит, то смотрим маршруты непосредственно на VPN-сервере (на самом деле клиенте) или проверяем брандмауэр на другой стороне.

Если мы сами сервер – то в первую очередь проверяем подключен ли к нам клиент со стороны D, далее точно также – маршруты и брандмауэр.

Другое дело stateless туннели, это GRE, IP-IP и WireGuard. Они ничего не знают о состоянии другой стороны и всегда подняты. В этом случае проверяем доступность узла противоположной стороны – Y, проверяем параметры туннеля с обоих сторон, правильность настроек.

Потому что в случае неправильных настроек туннельные интерфейсы с обоих сторон все равно будут подняты, также они будут подняты даже если узлы X и Y будут недоступны.

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

В этом случае проверяем, включена ли маршрутизация на VPN-сервере с другой стороны, смотрим, не блокирует ли нас брандмауэр, а после этого смотрим, умеет ли узел F отправлять пакеты в сеть узла A. Для этого лучше всего выполнить встречную трассировку.

Ну и конечно же убедитесь, что все конечные и промежуточные узлы могут отвечать на пинг, например, Windows с настройками брандмауэра по умолчанию этого не делает.