создаем виртуальный туннель с помощью VTun
Я попытаюсь описать в этой статье, мои дорогие читатели, некоторые аспекты создания виртуальных туннелей посредством замечательного во всех отношениях приложения VTun. Просто я решил поделиться своим опытом создания туннеля между моим собственным ноутбуком и офисной сетью, от которой я на момент написания этой статьи находился в 3 тысячах километров. Надеюсь, что он (этот мой опыт) будет кому-нибудь полезен.
Согласитесь, такие ситуации вполне возможны: ты уезжаешь из офиса, и вдруг оказывается, что ты (как разработчик, например) там нужен, причем твой лаптоп должен как бы стать офисной машиной, чтобы ты мог использовать wiki, bug tracking систему, тестовые серверы, почту, CVS-сервер, да мало ли что еще? Во всех нормальных офисах это возможно только из локальной сети. О том, как стать ее частью, мы здесь и поговорим.
задача, которую надо решить
Итак перейдем, собственно, к делу после этого затянувшегося вступления (признаться, никогда не любил писать вступления). Будем считать, что мы имеем на лаптопе нормальный Linux (любой подойдет, главное, чтобы у хозяина руки были прямые) и не совсем тривиальную ситуацию, когда офисная сеть спрятана за двумя гейтвеями, на которые у нас есть доступ. Пусть также в любимом офисе стоит и ждет нас Linux-box, на котором мы обычно работаем в так называемое рабочее время. Итак, конфигурация проста:
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 и компилим его благополучно (на обе машины, разумеется, то есть на клиент и на сервер). Если у вас возникают проблемы с компиляцией, значит Linux вы себе поставили не полностью или у вас плохой дистрибутив (чуть было не нарисовал смайлик). В этом случае смело делайте:
./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, который будет определяться вашей сетевой конфигурацией в офисе). Будьте, однако внимательны: адреса туннельных интерфейсов на сервере и на клиенте должны совпадать.
Будем считать, что вы поместили оба конфига на клиент и сервер соответственно и готовы к подъему туннеля. Начните с сервера (ключ -s говорит о запуске сервера).
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’ов портов, см. выше).
Контролировать процесс запуска можно, просматривая в релаьном времени /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@sai.msu.ru.
Иван Золотухин.
Согласитесь, такие ситуации вполне возможны: ты уезжаешь из офиса, и вдруг оказывается, что ты (как разработчик, например) там нужен, причем твой лаптоп должен как бы стать офисной машиной, чтобы ты мог использовать wiki, bug tracking систему, тестовые серверы, почту, CVS-сервер, да мало ли что еще? Во всех нормальных офисах это возможно только из локальной сети. О том, как стать ее частью, мы здесь и поговорим.
задача, которую надо решить
Итак перейдем, собственно, к делу после этого затянувшегося вступления (признаться, никогда не любил писать вступления). Будем считать, что мы имеем на лаптопе нормальный Linux (любой подойдет, главное, чтобы у хозяина руки были прямые) и не совсем тривиальную ситуацию, когда офисная сеть спрятана за двумя гейтвеями, на которые у нас есть доступ. Пусть также в любимом офисе стоит и ждет нас Linux-box, на котором мы обычно работаем в так называемое рабочее время. Итак, конфигурация проста:
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 и компилим его благополучно (на обе машины, разумеется, то есть на клиент и на сервер). Если у вас возникают проблемы с компиляцией, значит Linux вы себе поставили не полностью или у вас плохой дистрибутив (чуть было не нарисовал смайлик). В этом случае смело делайте:
./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, который будет определяться вашей сетевой конфигурацией в офисе). Будьте, однако внимательны: адреса туннельных интерфейсов на сервере и на клиенте должны совпадать.
Будем считать, что вы поместили оба конфига на клиент и сервер соответственно и готовы к подъему туннеля. Начните с сервера (ключ -s говорит о запуске сервера).
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’ов портов, см. выше).
Контролировать процесс запуска можно, просматривая в релаьном времени /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@sai.msu.ru.
Иван Золотухин.
Сетевые решения. Статья была опубликована в номере 11 за 2005 год в рубрике sysadmin
