VPN микрорайонного масштаба

Алексей Федорчук
18 апреля 2006 г

В этой заметке я расскажу о своем общении с провайдером микрорайонного масштаба. Какого провайдера и из какого микрорайона — не скажу (кроме того, что речь идет о городе-герое Москве), так как, по полученным мною сведениям, все они примерно одинаковы, так что обижать никого не хочу. Надеюсь, что изложенное далее будет полезным и за пределами описанной местности — для тех, кто придерживается нестандартной ориентации в отношении используемых операционок.

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

Конечно, в качестве почти универсального (для Москвы) варианта оставался Стримм — но от них я очень долго не мог получить ответа на запрос о пригодности моей телефонной линии (надо сказать, что у соседей по подъезду Стримм работал вполне успешно).

И вот тут я и наткнулся на предложение микрорайонного масштаба, показавшееся мне весьма привлекательным: бесплатное подключение, безлимитный тариф — 600 рублев для скоростей 200/128 Кбит/с (входящей и исходящей, соответственно). То есть примерно то же самое, что было у меня раньше (и за те же примерно деньги, соответствующие среднестатистическим московским реалиям сегодняшнего дня). Поэтому я опрометчиво не задал никаких технических вопросов. Впрочем, если бы и задал — это мало чего изменило бы, ведь ответа от Стримма все еще не было, а других альтернатив на горизонте микрорайона не просматривалось.

В общем, оставил я заявку на подключение. Обещали сделать это в течении двух недель. И слово свое сдержали, монтажники появились день, если не изменяет память, на двенадцатый (замечу, что от их офиса до моего дома по кривой — метров 200).

Что такое бесплатное подключение в микрорайонных условиях — распространяться особо не буду, это легко представит себе каждый, кто пользовался бесплатными услугами на постсоветских пространствах. Отмечу только — сетевая карта (если не имеется собственной — у меня была, встроенная в ноутбук) в понятие бесплатности не входит. Как и любые другие аксессуары, за исключением собственно витой пары. Хотя, нужно отдать должное моим монтажникам, на кабель они не поскупились, кинув его с двойным, как минимум, запасом (о прокладке при бесплатном подключении речи, разумеется, тоже не было).

Дальше было еще несколько мелких заморочек, на которых останавливаться не буду. В итоге все кончилось тем, что сеть физически была подключена, и лампочка на моей сетевухе замигала. А после этого началось самое интересное.

Дело в том, что ни на одной моей машине уже в течении многих лет нет никакого намека на Windows. А есть лишь Linux или (иногда — и) какая-либо из BSD-систем. В частности, в тот момент (и по сию пору) стоял на ней Linux Kubuntu Dapper (5-я пре-релизная версия). А вот как подключать его к сети — провайдеры не имели ни малейшего представления. И даже задали вопрос — а почему бы мне не поставить Windows для подключения к Инету? На что я резонно ответил, что, подобно той даме, что в раннеперестроечные времена написала известную статью в журнале «Огонек», принципами не поступаюсь. И скорее готов отказаться от услуг провайдера, не способного обеспечить в своей сети работу машины под свободной операционкой.

Дело осложнялось тем, что никакого DHCP-сервера у провайдера не имелось — внутрисетевые IP выдавались статически. А имелась зато авторизация по VPN, снискавшая уже нежную «любовь» среди линуксоидов. И в адрес которой я на Linux-форумах слышал много слов (все больше нежных и ласковых, исконно русских, от бороны, что называется).

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

Итак, уходя, провайдеры оставили мне, кроме мигающей лампочки, также конверт со следующим содержимым:

  • внутрисетевой IP-адрес;
  • маску подсети;
  • IP-адреса шлюза, 1-го и 2-го DNS;
  • имя (не адрес) VPN-сервера — внутреннее, в форме труляля.ok;
  • пароль и логин для авторизации на нем;
  • прочие мелочи, вроде URL интранет-сервера (с характерным именем www.ok), страницы личной статистики, и так далее.

Очевидно, что для начала следовало настроить доступ к внутренней сети провайдера. Сделать это в моих условиях трояко: руками из командной строки, текстовым редактором через конфигурационные файлы и автоматически — средствами администрирования Kubuntu (точнее, средствами, которые Kubuntu заимствовала от своего умолчального десктопа — KDE).

Чисто ручной способ сводится к вводу команды ifconfig с указанием имени сетевого интерфейса (в данном случае — eth0), собственного IP-адреса и маски подсети. На нем я задерживаться не буду — детали можно посмотреть в man ifconfig.

Для ручной настройки достаточно было вписать в файл /etc/network/interfaces (напоминаю — речь идет о Kubuntu, то есть с точки зрения конфигурирования, практически о Debian — в более иных дистрибутивах потребовалось бы править другие конфиги) строки следующего вида:

# Указание на статически внутрисетевой IP
iface eth0 inet static
# Собственно внутрисетевой IP
address
# Полученная от провайдера маска подсети
# В большинстве случаев она именно такова
netmask 255.255.255.0
# IP-адрес шлюза
gateway
# IP-адреса 1-го и 2-го сервера имен, через пробел
dns-nameservers

# Предписание запускать сетевую службу при старте машины
auto eth0

Наконец, автоматизированный метод — это вызов через K-меню KDE пункта System Setting, и выбор в секции Сеть и Интернет иконки Настройка сети. Этот метод применим для всех пользователей KDE — разве что в других дистрибутивах понадобится вызывать KCC (KDE Control Center), а уж в нем отыскивать, где настраивается сеть.

Но в принципе ничего сложного тут нет. Посредством соответствующей кнопки нужно перейти в режим администратора, введя пароль (обычного пользователя — в Kubuntu, root’а — в большинстве прочих дистрибутивов. Далее из списка на первой вкладке (Network Interfaces) выбирается нужный интерфейс (скорее всего, eth0 — рис. 1), щелчок на нем правой клавишей вызывает контекстное меню, в котором следует указать пункт Configure interface. А затем в появившейся панели остается только вбить полученные от провайдера свой IP’шник, сетевую маску и Gateway (он же шлюз — рис. 2). После чего, перейдя на вкладку Domain Name Systen, последовательно добавить адреса первичного и вторичного DNS-серверов.

vpn_ris01Рис. 1. Выбор сетевого интерфейса…

vpn_ris02Рис. 2. …и его конфигурирование

Проверка правильности настройки сети осуществляется в три этапа. Сначала командой

$ ifconfig eth0

смотрим, соответствуют ли сетевые параметры вывода тому, что было нами указано (впрочем, при ручном вводе они и не могут быть иными). Затем командой

$ ping www.ok

пропинговываем интранет-сервер провайдера. И, наконец, заходим на этот самый интранет-сайт через браузер, указав в его адресной строке URL — www.ok.

Я проделал все эти действия успешно, в результате чего получил доступ к внутреннему FTP-серверу (не буду говорить о его содержании). Но ни малейшего Интернета, разумеется, не было. Так что настала пора переходить к снастройке VPN-подключения.

Это дело требует в первую очередь поддержки протокола PPTP (Point-to-Point Tunneling Protocol). Клиентская его часть (а большего в данном случае и не требуется) обеспечивается пакетом, который в deb-клонах носит название pptp-linux. Авторское его имя, кажется, — linux-pptp, во FreeBSD он зовется pptp-client, в других системах и дистрибутивах возможны и иные имена — в каждом конкретном случае это следует уточнить штатными средствами системы пакетного менеджмента.

Впрочем, пакет этот вовсе и не обязан присутствовать в произвольном дистрибутиве. Так, в репозитории Archlinux я его не обнаружил. Так что пользователям этого дистрибутива придется начинать настройку VPN с ручной сборки linux-pptp (или написания build-файла для его построения).

Однако, на мое счастье, в Kubuntu такой пакет имелся — и, более того, находился даже на дистрибутивном диске, хотя и не устанавливался по умолчанию при инсталляции системы. И с зависимостями у него оказалось небогато — все-то что

Depends: libc6 (>= 2.3.4-1), ppp (>= 2.4.2)

каковые и так имели место быть установленными. Так что, выполнив

$ dpkg -i /media/cdrom/pool/main/p/pptp-linux

я легко получил поддержку искомого протокола. А дальше, как обычно бывает в Linux’е, «средь мира дольного, для сердца вольного», лежали «два пути». Правда, в данном случае их оказалось целых три:

  • загрузить pptp руками из командной строки;
  • использовать скрипт для установки VPN-соединения;
  • прибегнуть к какому-либо front-rnd-конфигуратору.

От «ручного запуска» я отказался — да это и не решение задачи, каждый раз запускать pptp руками. Обратившись по началу к напрашивающемуся варианту — скриптовому запуску. И надо заметить, что скриптов для этого дела в сети можно раскопать немало. Да и на форумах нашей тематики тема эта была жёвана-пережёвана. В общем, казалось бы, недостатка в информации не предвиделось.

Ан не тут-то было. Ни один из найденных мной скриптов «в лоб», после соответствующей коррекции реалий, не заработал. Причём ситуация была самая скверная: нельзя сказать, что они не работали вообще (сообщений об ошибках не поступало), но и назвать это работой язык не поворачивался. А именно: VPN-соединение после отработки, например, специально Debian’овского скрипта устанавливалось. Это можно было видеть и через ps (соответствующие процессы в списке присутствовали), и через ifconfig -a, который показывал появление интерфейса ppp0. Но держалось оно считанные мгновения, не позволявшие даже запустить команду ping. Однако из этого следовал и позитивный вывод — видимо, что-то не так в консерватории, то есть в параметрах, данных провайдером. Как станет ясным из дальнейших событий, так оно и оказалось.

Оставалась последняя надежда — автоматический конфигуратор. Таковой поначалу обнаружился в единственном числе, выступая под именем pptpconfig. В репозитории Ubuntu его не оказалось, но на авторской странице можно, кроме исходников и rpm’ок, найти также и deb-пакеты, причем вместе с основными зависимостями — php-pcntl и php-gtk-pcntl. Правда, последние тянут за собой рекурсивно зависимости собственные. Тем не менее, с помощью модема, dpkg и чьей-то матери задача установки pptpconfig решаема. По крайней мере, мне это сделать удалось.

И так, pptpconfig запускается с правами администратора, то есть в Ubuntu/Kubuntu так:

$ sudo pptpconfig

После чего перед глазами появляется следующее окно (рис. 3).

vpn_ris03Рис. 3. Создание туннеля

В соответствующие поля формы вбиваем имя туннеля (то есть соединения — в моем случае оно могло быть произвольным набором символов), IP’адрес VPN-сервера (говорят, что можно и его внутрисетевое имя, но у меня это не сработало), полученные от провайдера логин и пароль (поле Domain остается пустым).

Откуда взялся адрес VPN-сервера? Ведь, как вы помните, провайдер оставил мне в конвертике только его внутрисетевое имя. Определит адрес по URL можно различными путями, я воспользовался командой

$ host труляля.ok

каковая и выдала мне искомый IP’шник.

Заполнив таким образом форму Server, я, в соответствие с инструкциями, перешел на закладку Encryption, где, вместо отмеченного по умолчанию пункта MPPE, включил пункт, говорящий про EAP (рис. 4).

vpn_ris04Рис. 4. Настройка Encryption

Теперь остается только кнопкой Add добавить новосозданный туннель в список и, отметив его курсором, нажать кнопку Start для проверки. Нажатие ее приводит к открытию нового окна (рис. 5), в котором проверку можно выполнить посредством кнопки Ping.

vpn_ris05Рис. 5. Окно статуса соединения VPN

К моей радости, пинги с новым внутренним сервером прошли успешно. Более того, команда

$ ifconfig -a

показала наличие интерфейса ppp0 (никуда теперь не исчезающего) с новыми параметрами — моим IP-адресом (прежний, для eth0, начинался со 192, этот же — со 172), адресом P-t-P (он, собственно, и пинговался при тесте) и новой маской подсети.

Теперь, в соответствие с инструкцией, оставалось последнее действие: сделать только что созданный канал доступным для программ. Для этого останавливаю соединение (кнопкой Stop в любом из двух окон) и в окне настройки перехожу на вкладку Routing, включаю в ней пункт All to Tunnel вместо умолчального Client to Lan (рис. 6) и кнопкой Start активизирую туннель заново. Теоретически после этого можно, например, выйти в Интернет любым браузером.

vpn_ris06Рис. 6. Делаем канал доступным

В этот момент радость моя и закончилась. Попытки открыть какой-либо сайт успехом не увенчались. Пинги не проходили ни на один внешний URL. Более того, и внутрисетевые URL’ы пинговаться перестали.

Так и пребывал бы я в растерянности, если бы не советы знакомых админов — пропинговать внешние сервера не по URL, а по IP-адресам. И — о чудо — пинги пошли. Стало ясно, что дело в настройках DNS. просмотр файла /etc/resolv.conf показал, что вместо прежних их адресов появились новые — совершенно мифического облика. Ничтоже сумняшеся, я вписываю туда IP своего служебного DNS-сервера. После чего наконец обретаю выход в Интернет.

Теперь у меня вроде все нормально — но получать имена со стороны не есть правильно с точки зрения быстродействия. Надо найти способ сделать это внутренними силами сети провайдера. Благо, в окне настройки pptpconfig для этого имеется соответствующая закладка — DNS, в которой по умолчанию сервера имен определяются автоматически (рис. 7). И, как показала практика, неправильно. Однако никто не мешает отключить автоматику и вписать в соответствующую строку адрес DNS-сервера провайдера (с моим служебным сервером имен это прошло нормально). Если бы не одно но: для этого адрес этот хорошо бы знать.

vpn_ris07Рис. 7. Указание DNS-сервера

Теоретически узнать IP сервера имен можно было бы, вероятно, спросить у провайдера непосредственно. Однако дело происходит в выходные дни, и попытки дозвониться до их службы техподдержки успехом не увенчались. А ждать до понедельника — терпения не хватало. И тогда я, временно оставив DNS с моей службы, прибег к команде nslookup. Данная с аргументом — доменным именем, она выводит как адрес используемого сервера имен, так и реальный IP, к которому это имя привязано:

$ nslookup name.ru
Server:  IP
Address: IP#port

Name:   name.ru
Address: IP

Теперь оставалось только перебрать доменные имена моего провайдера (благо, их было немного) и методом ползучего эмпиризма определить IP того из них, которое сошло бы за DNS-сервер, после чего вписать его в строку соответствующей закладки окна VPN-конфигуратора (см. рис. 7). С этого момента я наконец смог наслаждаться полноценным Интернетом…

Правда, пока для этого требуется не только вызвать pptpconfig из командной строки терминала через sudo, но и запустить собственно соединение кнопкой Start. Что не то чтобы обременительно — но создает чувство некоторого дискомфорта, заствляя вспомнить старое, но недоброе модемное время.

Вторая проблема устраняется легко. В окне конфигуратора нужно перейти к закладке Miscellaneous, в которой включить пункт Start tunnel when this programm starts и, на всякий пожарный случай, Reconnect is disconnected (рис. 8, смысл, думаю, понятен без перевода).

vpn_ris08Рис. 8. Запуск туннеля одновременно с запуском pptpconfig

Решения первой задачи я пока не нашел. Вследствие особенностей дистрибутивов Kununtu (отсутствия root-аккаунта как такового) со стандартными средствами типа запуска от имени другого пользователя, у меня ничего не вышло. Придется думать дальше. Ну и если кто подскажет — буду весьма признателен.

Какой вывод можно сделать из моей истории? Перефразируя слова Александра Дюма, заключаю: не следует верить ни тому, что говорят провайдеры, ни тому, что говорят их враги. Соединение VPN в Linux наладить вполне можно. Нужно только, если это не получается с первой же попытки, затратить некоторое время на перебор вариантов. Используя прямые IP, не полагаясь на данные, полученные при подключении.

Я понимаю, что все описанное выше способно вызвать у профессионального сетевика лишь ироническую улыбку. Однако как пользовательское решение оно вполне работает — и для меня (а также, подозреваю, большинства обычных пользователей) это главное.

Кстати говоря, описанный метод настройки VPN — далеко не единственный. Прошерстив через

$ apt-cache search vpn

репозитории Ubuntu (с чего, собственно, и нужно было бы начать по хорошему, если бы не нетерпеливое вожделение Сети), я обнаружил несколько VPN-клиентов и немало front-end’ов для них, например — kvpnc, предназначенный, как явствует из имени, специально для KDE. И, следовательно, более подходящий для использования в Kubuntu. Возможно, что с какими-то из этих программ результата можно было бы добиться быстрее и проще. Впрочем, этот вопрос я надеюсь исследовать и описать в ближайшее время.

При настройке своего многострадального соединения автор пользовался постоянной поддержкой Игоря Борейко, бессменного админа куста контор моей бывшей службы. Игоря позвали верхние люди. Светлая память…

1 комментарий к “VPN микрорайонного масштаба

  1. Ситуация знакомая — ток в моем случае она была еще более запутанная:
    vpn устанавливалась не на прямую к провайдеру — а через шлюз представлющий из себя кабельный модем (настроенный провайдером не прозрачно а с физическим ip аддресом). В результате для подключения к vpn требовалось кинуть маршрут по умолчанию к модему, а после подключения к впн этот маршрут заменялся на маршрут по умолчанию забранным автоматически при соединении — соответсвенно впн обваливался. Если не давать срабатывать автоматическому выставлению маршрута, то тогда не работал инет … так как маршрут продолжал смотреть на шлюз — а не по ту сторону впн ….. Решалось все на редкость просто, — к модему создавался не default gateway а статический маршрут, тогда при соединении спокойно создавался default маршрут через впн, без потери связи с модемом — и инет в этой системме работал нормально.

    п.с: для меня это было не концом бед — в нашем мухосранске (астрахани) комуникации не менялись со времен революции (ну не дошла до нас отечественная война) и потому связь вечно падала уволакивая за собой с таким трудом поднятый впн :) . Потому пришлось ставить еще сторожащий ppp0 скрипт прикрученный к cron, который проверял каждую минуту наличие этого интерфейса в системме — и при отсутсвии поднимавший падшего. Подобных сторожей с тех пор ставлю всегда потому что беда с комуникациями касается любой связи любых провайдеров нашего города (даже оптоволокно нп работе)

Обсуждение закрыто

Перейти к верхней панели