Создание виртуальных туннелей с помощью VTun

http://chernowiki.ru

🕛 29.05.2007, 12:49

Вступление

Я (important note: автор не являеется системным администратором, он, по сути, никем не является) попытаюсь описать в этом документе, мои дорогие читатели, некоторые аспекты создания виртуальных туннелей посредством замечательного во всех отношениях приложения VTun. Просто я решил поделиться своим опытом создания туннеля между моим собственным ноутбуком и офисной сетью, от которой я на момент написания этой статьи находился в 3 тысячах километров, в надежде, что он (этот мой опыт) будет кому-нибудь полезен.
Согласитесь, такие ситуации вполне возможны: ты уезжаешь из офиса, и вдруг оказывается, что ты (как разработчик, например) там нужен, причем твой лаптоп должен как бы стать офисной машиной, чтобы ты мог использовать wiki, bug tracking систему, тестовые сервера, почту, CVS сервер, да мало ли что еще? Во всех нормальных офисах это возможно только из локальной сети. О том, как стать ее частью, мы здесь и поговорим.

Задача, которую надо решить

Итак, перейдем, собственно, к делу, после этого затянувшегося вступления (признаться, никогда не любил писать вступления). Будем считать, что мы имеем на лаптопе нормальный Linux (любой подойдет, главное, чтобы у хозяина руки были прямые) и не совсем тривиальную ситуацию, когда офисная сеть спрятана за двумя гейтвеями, на которые у нас есть доступ. Пусть также в любимом офисе стоит и ждет нас Linux-box, на котором мы в этом самом офисе и работаем в так называемое рабочее время. Итак, конфигурация проста (названия машин и их IP адреса, где это нужно):

laptop (192.168.11.13) - gw - officegw - pc (192.168.100.192)

SSH port forwarding

laptop стоит в одной внутренней сети, pc - в офисной сети, в которую нам нужно попасть, например, с адресом 192.168.100.202. В данной ситуации с gateway-ями, предлагается сделать машину pc сервером для туннеля, а ваш лаптоп будет выступать в роли клиента. Для начала, необходимо получить прямой раут с laptop на pc, который затем будет и использоваться для туннеля. Это удобно делать с помощью удобной такой фичи протокола ssh под названием SSH port forwarding (любопытные могут уже сейчас набирать man ssh и искать там ключик -L или -R), приблизительно в такой последовательности:
Код:
ssh iz@gw
su ssh -g -L 7777:localhost:7777 iz@officegw

Что мы только что сделали? Мы зашли на машину gw, и прокинули 7777 порт на такой же на машине officegw, причем разрешили внешние коннекты на него (опция -g). Сделав теперь, например
Код:
telnet gw 7777

мы законнектимся уже с машиной officegw (с ее 7777-м портом), если там кто-то слушает этот порт, хотя раньше не могли напрямую попасть на officegw. Правильно тут кто-то подумал, если бы мы пробросили 7777 порт gw на 22-ой officegw, то по
Код:
ssh -p 7777 gw

мы бы попадали на SSH daemon машины officegw. Видите теперь, как все просто?
Далее, заходим на officegw и делаем тоже самое (из-под root, так как только привилегированный пользователь может разрешать внешние соединения ключом -g):
Код:
ssh -g -L 7777:localhost:5000 iz@pc

Мы получили таким образом, следующую цепочку (надеюсь, моя псевдографика не вызовет ни у кого вопросов):

7777:gw -> 7777:officegw -> 5000:pc

То есть соединяясь с портом 7777 машины gw нас будет кидать прямо в офис на порт 5000 машины pc. Ура, 10% дела сделано, теперь приступаем к установке туннеля, теперь ведь у нас есть прямой маршрут с laptop на pc.

Установка VTun

Качаем VTun с указанного выше сайта под названием SourceForge и компилим его благополучно (на обе машины, разумеется, то есть на клиент и на сервер). Если у вас возникают проблемы с компиляцией, значит линукс вы себе поставили не полностью или у вас плохой дистрибутив (чуть было не нарисовал смайлик). В этом случае смело делайте
Код:
./configure -help

и смотрите, что вы можете выключить, например
Код:
./configure -disable-lzo

рекомендуется делать людям, у которых не установлен LZO, а компрессия туннелированного траффика не очень нужна. Всегда помните, что даже у configure есть help.
ОК, будем считать, VTun поставился. После
Код:
modprobe tun

у вас даже ядро его будет поддерживать (чё-то я расшутился и вышел за пределы формата, на Петросяна немного похоже даже).

Конфигурация VTun

Итак, поприветствуем людей, которые все знали про SSH port forwarding и хотели узнать только про виртуальные туннели, им следует начинать читать с этого места. Давайте сначала рассмотрим конфигурационный файл для клиента:
Код:
options { port 7777; # Connect to this port. timeout 60; # General timeout # Path to various programs ppp /usr/sbin/pppd; ifconfig /sbin/ifconfig; route /sbin/route; firewall /usr/sbin/iptables; ip /sbin/ip;
}

myvpn { pass xxxxxxxx; # Password device tun1; # Device tun1 proto tcp; persist yes; # Persist mode up { # Connection is Up
# Assign IP addresses. ip "link set %% up multicast off mtu 1450"; ip "-family inet addr add 192.168.100.202 peer 10.0.0.1 dev %%"; ip "route add 192.168.0.0/16 via 192.168.100.202 dev %%"; # UNCOMMENT if you need default routing #ip "route add default via 192.168.100.222 dev %%";
};
}

Соответствующей нашей задаче серверный конфиг будет таким:
Код:
options { port 5000; # Listen on this port.
# Syslog facility syslog daemon;
# Path to various programs ppp /usr/sbin/pppd; ifconfig /sbin/ifconfig; route /sbin/route; firewall /usr/sbin/iptables; ip /sbin/ip;
}
# Default session options
default { compress no; # Compression is off by default speed 0; # By default maximum speed, NO shaping
}
# the same as above, but with iproute2 command
myvpn { pass xxxxxxx; type tun; # IP tunnel proto tcp; # TCP protocol encr no; # Encryption keepalive no; # Keep connection alive
up { # Connection is Up # 10.0.0.1 - local, 192.168.100.202 - remote program "/sbin/arp -i eth0 -d 192.168.100.202 pub"; ip "link set %% up multicast off mtu 1450"; ip "-family inet addr add 10.0.0.1 peer 192.168.100.202 dev %%";
program "/sbin/arp -i eth0 -Ds 192.168.100.202 eth0 pub"; }; down { program "/sbin/arp -i eth0 -d 192.168.100.202 pub"; };
}

Теперь, когда вы имеете необходимые конфиги для VTun-а, давайте посмотрим на них более внимательно. Сервер у нас будет слушать порт 5000, а клиент - соединяться с портом 7777, потому как выше мы пробрасывали именно эти порты с помощью SSH port forwarding. Как вы понимаете, номера портов - полностью условны, можете выбирать любые другие. Далее, несколько комментариев в произвольном порядке:

* в серверном и клиентском конфигах пароли в соответствующих секциях должны обязательно совпадать
* в серверном конфиге encryption нужно отключить (у нас итак траффик будет шифрован по причине SSH port forwarding)
* по этой же причине в качестве протокола выбираем tcp, а типа туннеля - tun (читайте об этом в манах VTun-а) или просите меня в комментариях разъяснить вам это дело (обязательно прокомментирую, если хоть одна душа попросит)
* адрес 10.0.0.1 для туннельного интерфейса офисной машины pc - чистая условность, можно было выбрать любой другой (впрочем, как и адрес 192.168.100.202, который будет определяться вашей сетевой конфигурации в офисе). Будьте, однако внимательны: адреса туннельных интерфейсов на сервере и на клиенте должны совпадать

адрес 10.0.0.1 для туннельного интерфейса офисной машины pc - чистая условность, можно было выбрать любой другой (впрочем, как и адрес 192.168.100.202, который будет определяться вашей сетевой конфигурации в офисе). Будьте, однако внимательны: адреса туннельных интерфейсов на сервере и на клиенте должны совпадать
Код:
vtund -s -f /place/to/find/above/vtund.conf.server

а потом на клиенте:
Код:
vtund -f /place/to/find/above/vtund.conf.client myvpn gw

где myvpn - название секции (это значит, что в одном конфигурационном файле их может быть произвольное число), а gw, как вы должны помнить - название машины, к которой мы коннектимся (а дальше уже все бежит по цепочке SSH forward-ов портов, см. выше).
Контролировать процесс запуска можно с помощью tail -f /var/log/messages, так как в такой конфигурации vtund логгируется с помощью syslog-а. Если туннель нормально поднялся, то на клиенте вы должны видеть сетевой интерфейс tun1, а на сервере с приведенным конфигом - tun0.
Проверить работу туннеля с клиента можно просто пингом
Код:
root@laptop:~# ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=398 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=397 ms

Пинги, отличные от долей миллисекунды должны указывать нам на те тыщи километров, которые пролетают наши пакетики (в моем случае, эх, они через всю Землю кругом, пожалуй, летают). Соответственно, должны работать пинги и с сервера на клиента.
Теперь смотрим, что у нас происходит с маршрутизацией. Да, никакой arp-фильтрации на сервере быть не должно, разумеется. Попробуем пингануть какую-либо офисную машину с laptop (при условии, конечно, что в нормальном состоянии она отвечает на пинги), если все заработало, то вы у цели. Если нет, то проверяем, не запрещен ли у вас на сервере туннеля форвард пакетов:
Код:
root@pc:~# cat /proc/sys/net/ipv4/ip_forward
0
root@pc:~# echo 1 > /proc/sys/net/ipv4/ip_forward

После этого все должно заработать. Если не заработало, вам могут помочь следующие команды:
Код:
arp -an
route -n

Если совсем не получилось и все вышеуказанные требования выполнены - пишите сюда, будем разбираться. Если машины начали пинговаться (как и должно произойти), то вы выиграли - вы теперь часть офиса, как и остальные машины. Спокойно прописываете в /etc/resolv.conf офисный nameserver (если у вас присутствует какая-нибудь маргинальность в офисе с именами) в качестве одного из них и начинаете работать.

Заключение

Следуя приведенному подходу, легко можно организовать shfsmount своей офисной машины на локальный драйв. Дальше запускаете любимый редактор и Skype - и вы часть девелоперской команды. Вы никуда не уезжали, вы сидите в теплых тапочках в своем офисе...

Благодарности

* Филиппу Прунелю за то, что вытащил меня из офиса
* Николаю Самохвалову, за то, что затащил меня назад в офис
* Сергею Силкину, за раздолбайство и отсутствие возможности все сделать за меня
* Игорю Чилингаряну за instant messaging и помощь с VTun-ом
* Максиму Краснянскому за VTun, уважаю.

any feedback is welcome at iz at sai dot msu dot ru