Туннелирование и подмена адреса источника на ViPNet HW1000 координаторе

Как-то потребовалось организовать доступ к веб-серверу через неизвестную сеть по защищённому каналу. Защита базируется на ViPNet – имеется координатор и клиенты, подключаемые через Интернет. Проблема была в том, что веб-сервер находился в другой сети, доступа в которую у меня не было.

Приблизительно набросал вот такую схему:Здесь ViPNet Client подключается к HW1000 координатору через сеть Интернет. Также имеется сеть 10.15.12.0/24 (на самом деле 29, это так, для простоты), в которой имеется маршрутизатор .1. За этим маршрутизатором ещё чёрти что может быть, я точно не знаю. Но вот где-то там дальше и есть 10.220.A.B узел, до которого и нужно сделать доступ.

Получил у администратора сети 10.15.12.0/29 IP-адрес, который повесил на интерфейс координатора. Теперь пинги доходят до 10.15.12.1, потому что он находится в той же сети. Но как дальше? Создал маршрут:

inet route add 10.220.A.B gw 10.15.12.1 netmask 255.255.255.252 (почему-то маску 255.255.255.255 координатор не воспринимает).

Но пакеты не ходят. Проблема в том, что подключившиеся по ViPNet сети клиенты имеют виртуальные IP-адреса вида 10.0.0.0/24, и маршрутизация начинает загонять.

Почитав немного мануалы решено было делать трансляцию адреса, а именно src-nat. Вообще этот метод обычно используется для того, чтобы выпустить локального клиента в глобальную сеть, подменив адрес источника клиента на адрес шлюза. Но здесь ситуация обратная, хотя технология та же. По документации мне предлагалось делать dst-nat, но нужен именно src-nat.

Итак, создаём правило:

rule =num 1 change src=10.15.12.7 proto tcp from any to 10.220.A.B

То есть для всех пакетов, адресом назначения которых является 10.220.A.B подменить адрес источника на адрес координатора. Как будто бы это от него исходит пакет. Тогда он без проблем проходит все остальные устройства до цели.

При этом в таблице трансляции будет создана соответствующая запись, позволяющая вернуть пакет обратно.

Кстати, если используете подобный форвардинг – убедитесь, что правила цепочек forward и tunnel не запрещают прохождение пакетов.

Ах, да! Ну и в свойствах координатора нужно указать tunnel= 10.220.A.B-10.220.A.B to 10.220.A.B-10.220.A.B.

Тогда он будет понимать, что пакеты, предназначаемые для этого назначения ему нужно маршрутизировать.