Маршрутизация в vpn сети - как настроить.

[Andrew SWH]

Решил я поднять VPN, ибо у родителей комп за NAT'ом, у бабушки айпишник вечно меняется... Инструкцию взял тут - http://www.xakep.ru/post/54795/default.asp и настроил VTun. Собственно, с самим VPN соединением никаких проблем нет: клиенты на "ура" цепляются к серверу, в обе стороны трафик идет без проблем. А вот клиенты друг друга не видят. То есть если сервер 10.1.0.1, а клиенты .2 и .4, то второй и четвертый сервер .1 к которому подсоединены, видят, а друг друга - нет. Сначала решил, что надо прописать на сервере маршрутизацию внутри сети 10.1.0.* - но полез на сервер и увидел

$ route
Таблица маршутизации ядра протокола IP
Destination Gateway Genmask Flags Metric Ref Use Iface
10.10.10.2      *               255.255.255.255 UH    0      0        0 tun0
10.1.0.4        *               255.255.255.255 UH    0      0        0 tun2
10.1.0.2        *               255.255.255.255 UH    0      0        0 tun1
192.168.1.0     10.10.10.2      255.255.255.0   UG    0      0        0 tun0
192.168.0.0     *               255.255.255.0   U     1      0        0 eth0
10.10.10.0      10.10.10.2      255.255.255.0   UG    0      0        0 tun0
link-local      *               255.255.0.0     U     1000   0        0 eth0
default         192.168.0.1     0.0.0.0         UG    0      0        0 eth0

то бишь у меня под каждое соединение, кроме всего прочего, создается новое tun-устройство. Или так и должно быть и маршрутизацию каким-то образом надо между этими виртуальными интерфейсами делать?.. сомневаюсь, это слишком нелогично. Видимо, где-то все же в настройке клиентов ошибка.

Из документации -

# теперь описываем клиентов
  client1 {
  passwd p@ssVV0rD;
  # тип может быть: tun, ether, tty, pipe
  type tun;
  proto udp;
  encrypt yes;
  # speed 256:128;
  keepalive yes;
  # команда, выполняемая при подключении
  up {
  ifconfig "%% 10.1.0.1 pointopoint 10.1.0.2 mtu 1450
  #   при необходимости пробрасываем соединение
  #   firewall "-t nat -A POSTROUTING -s 10.1.0.2 -j MASQUERADE";
  };

# команда при отключении (необязательная)
  down {
  firewall "-t nat -F";
  ifconfig "%% down";
  };
}

собственно, все клиенты прописаны таким образом, меняется только имя. Ну и, тут видно, что поднимается интерфейс новый... а что надо сделать, чтобы к уже имеющемуся все цеплялось?..

[и́нок]

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

[Andrew SWH]

Нашел еще одну доку... Там прописано в примере два клиента, при чем команды у них разные... второй по рутингу цепляется к первому. При этом непотяно, что будет, если второй будет подсоединен раньше первого, ибо при запуске ПОТОМ первого не будет прописываться маршрутизация ко второму...

mashine1 {
passwd Ma;;*TU;
type tun;
proto udp;
encrypt yes;
keepalive yes;

up {

ifconfig "%% 192.168.0.1 pointopoint 192.168.0.3
mtu 1450";
};
}

mashine2 {
passwd Ma&^TU;
type ether;
device tap0;
proto udp;
compress zlib:5;
speed 256:128;
encrypt yes;
stat yes;
keepalive yes;

up {
ifconfig "%% 192.168.0.2 192.168.0.1
netmask 255.255.255.0";
route "add -net 192.168.0.0 netmask 255.255.255.0";
firewall "-A forward -s 192.168.0.0/24 -d 0.0.0.0/0
-j MASQ";
};

down {

ifconfig "%% down";
route "delete 192.168.0.0";
firewall "-D forward -s 192.168.0.0/24 -d 0.0.0.0/0
-j MASQ";
};
}

это для фряхи, но суть дела не в том.. Откуда у первой машины возьмется рутинг, если она подсоединится после второй, а не до?..

[и́нок]

Сообщение от Andrew SWH

это для фряхи, но суть дела не в том.. Откуда у первой машины возьмется рутинг, если она подсоединится после второй, а не до?..

Судя по несимметричности конфига вторая станция - сервер. Она и проталкивает новые роуты клиенту, параметры шифрования и т.д. Извини, могу ошибаться, бегло смотрел.

[Andrew SWH]

Не, конфиги сервера и клиента одинаковы. Только у сервера несколько одинаковых клиентских секций. Собственно, вопрос непосредственно к vtun'у отношения не имеет: там тупо запускаются указанные в конфиге команды при соединении с тем или иным клиентом или сервером. Те же самые команды можно и вручную в консоли вбить, вопрос не в этом... вопрос в том, как правильно настроить маршрутизацию в этой виртуальной впн-подсети.

Впрочем, кажется, грамотно сформулировав наконец вопрос, я сам на него себе и ответил: пойти почитать документацию по маршрутизации tcp/ip в линукс

Единственное, для укладки в голове. На клиентах я прописываю, что все пакеты для подсети 10.1.0.* (или 10.1.*.*, не важно) отправлять на 10.1.0.1, к которому все цепляются - это достаточно очевидно. А что нужно на машине, выступающей серевером соединений, чтобы она еще стала маршрутизировать пакеты между подключенными к ней клиентами. Я обойдусь одной командой route или, скорее, мне придется еще и со всякими iptables покопаться?..

На данный момент у меня на сервере тупо маршруты к непосредственным клиентам

10.1.0.3        *               255.255.255.255 UH    0      0        0 tun2
10.1.0.2        *               255.255.255.255 UH    0      0        0 tun1

ну а на клиентах аналогично лишь по одной строчке к серверу.

[и́нок]

Сообщение от Andrew SWH

что нужно на машине, выступающей серевером соединений, чтобы она еще стала маршрутизировать пакеты между подключенными к ней клиентами. Я обойдусь одной командой route или, скорее, мне придется еще и со всякими iptables покопаться?..

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

[Andrew SWH]

Здесь никаких директив нет, эта софтинка умеет только устанавливать соединение, а дальше тупо выполняет команды из конфига, запуская соответствующие системные утилиты типа route или iptables. Маршрут для клиента достаточно очевиден.

типа

route add -net 10.1.0.0 netmask 255.255.255.0 tun0

А вот для сервера - нет... ip_forward включен.

[Andrew SWH]

Чтение документации - вещь полезная, а маршрутизация в сетях TCP/IP - крайне увлекательна :-).

На клиенте
route add -net 10.1.0.0 netmask 255.255.255.0 gw 10.1.0.1 tun0

На сервере в конфиге каждого клиента (например, .2)
iptables -t nat -A POSTROUTING -s 10.1.0.2 -j MASQUERADE

Сижу, радуюсь собственной работоспособной vpn-сети :-)