Linux: приключения с VPN микрорайонного масштаба
В этой заметке я расскажу о своем общении с провайдером микрорайонного масштаба. Какого провайдера и из какого микрорайона - не скажу (кроме того, что речь идет о городе-герое Москве), так как, по полученным мною сведениям, все они примерно одинаковы, так что обижать никого не хочу. Надеюсь, что изложенное далее будет полезным и за пределами описанной местности - для тех, кто придерживается нестандартной ориентации в отношении используемых операционок.
Сменив некоторое время назад место жительства, я озаботился подключением к Сети. Прежнее мое логово было подключено к Интернету посредством выделенки от средне-крупного московского провайдера, о котором я не могу сказать ничего плохого, кроме хорошего. Однако в окрестностях нового моего обиталища равноценных предложений не обнаружилось.
Конечно, в качестве почти универсального (для Москвы) варианта оставался Стримм - но от них я очень долго не мог получить ответа на запрос о пригодности моей телефонной линии (надо сказать, что у соседей по подъезду Стримм работал вполне успешно).
И вот тут я и наткнулся на предложение микрорайонного масштаба, показавшееся мне весьма привлекательным: бесплатное подключение, безлимитный тариф - 600 рублев для скоростей 200/128 Кбит/с (входящей и исходящей, соответственно). То есть примерно то же самое, что было у меня раньше (и за те же примерно деньги, соответствующие среднестатистическим московским реалиям сегодняшнего дня). Поэтому я опрометчиво не задал никаких технических вопросов. Впрочем, если бы и задал - это мало чего изменило бы, ведь ответа от Стримма все еще не было, а других альтернатив на горизонте микрорайона не просматривалось.
В общем, оставил я заявку на подключение. Обещали сделать это в течении двух недель. И слово свое сдержали, монтажники появились день, если не изменяет память, на двенадцатый (замечу, что от их офиса до моего дома по кривой - метров 200).
Что такое бесплатное подключение в микрорайонных условиях - распространяться особо не буду, это легко представит себе каждый, кто пользовался бесплатными услугами на постсоветских пространствах. Отмечу только - сетевая карта (если не имеется собственной - у меня была, встроенная в ноутбук) в понятие бесплатности не входит. Как и любые другие аксессуары, за исключением собственно витой пары. Хотя, нужно отдать должное моим монтажникам, на кабель они не поскупились, кинув его с двойным, как минимум, запасом (о прокладке при бесплатном подключении речи, разумеется, тоже не было).
Дальше было еще несколько мелких заморочек, на которых останавливаться не буду. В итоге все кончилось тем, что сеть физически была подключена, и лампочка на моей сетевухе замигала. А после этого началось самое интересное.
Дело в том, что ни на одной моей машине уже в течении многих лет нет никакого намека на Windows. А есть лишь Linux или (иногда - и) какая-либо из BSD-систем. В частности, в тот момент (и по сию пору) стоял на ней Linux Kubuntu Dapper (5-я пре-релизная версия). А вот как подключать его к сети - провайдеры не имели ни малейшего представления. И даже задали вопрос - а почему бы мне не поставить Windows для подключения к Инету? На что я резонно ответил, что, подобно той даме, что в раннеперестроечные времена написала известную статью в журнале "Огонек", принципами не поступаюсь. И скорее готов отказаться от услуг провайдера, не способного обеспечить в своей сети работу машины под свободной операционкой.
Дело осложнялось тем, что никакого DHCP-сервера у провайдера не имелось - внутрисетевые IP выдавались статически. А имелась зато авторизация по VPN, снискавшая уже нежную "любовь" среди линуксоидов. И в адрес которой я на Linux-форумах слышал много слов (все больше нежных и ласковых, исконно русских, от бороны, что называется).
Ну, пока до отказа дело не дошло - отпустив ребят, я решил, что настроить сеть самому будет для меня делом чести, подвига и геройства. Должен признаться, что мой сетевой опыт до сего времени не намного поднимался над нулевым уровнем - вот заодно и решил сузить пробелы в своем образовании.
Итак, уходя, провайдеры оставили мне, кроме мигающей лампочки, также конверт со следующим содержимым:
Очевидно, что для начала следовало настроить доступ к внутренней сети провайдера. Сделать это в моих условиях трояко: руками из командной строки, текстовым редактором через конфигурационные файлы и автоматически - средствами администрирования 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-серверов.
Рис. 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 руками. Обратившись по началу к напрашивающемуся варианту - скриптовому запуску. И надо заметить, что скриптов для этого дела в сети можно раскопать немало. Например, решение, претендующее на универсальность, . Вариант для Gentoo . А при необходимости находится и очень внятное пошаговое не где-нибудь, а в Debian (на сей предмет есть и - правда, на английском). Да и на форумах нашей тематики тема эта была жевана-пережевана. В общем, казалось бы, недостатка в информации не предвиделось.
Ан не тут-то было. Ни один из найденных мной скриптов "в лоб", после соответствующей коррекции реалий, не заработал. Причем ситуация была самая скверная: нельзя сказать, что они не работали вообще (сообщений об ошибках не поступало), но и назвать это работой язык не поворачивался. А именно: VPN-соединение после отработки, например, специально Debian'овского скрипта устанавливалось. Это можно было видеть и через ps (соответствующие процессы в списке присутствовали), и через ifconfig -a, который показывал появление интерфейса ppp0. Но держалось оно считанные мгновения, не позволявшие даже запустить команду ping. Однако из этого следовал и позитивный вывод - видимо, что-то не так в консерватории, то есть в параметрах, данных провайдером. Как станет ясным из дальнейших событий, так оно и оказалось.
Оставалась последняя надежда - автоматический конфигуратор. Таковой поначалу обнаружился в единственном числе, выступая под именем pptpconfig. В репозитории Ubuntu его не оказалось, но можно, кроме исходников и rpm'ок, найти также и deb-пакеты, причем вместе с основными зависимостями - php-pcntl и php-gtk-pcntl. Правда, последние тянут за собой рекурсивно зависимости собственные. Тем не менее, с помощью модема, dpkg и чьей-то матери задача установки pptpconfig решаема. По крайней мере, мне это сделать удалось.
Обращение с pptpconfig достаточно подробно на сайте http://pptpclient.sourceforge.net, а также, как ни странно, на интранет-сайте моего провайдера (на примере Mandrake и Suse).
И так, pptpconfig запускается с правами администратора, то есть в Ubuntu/Kubuntu так:
$ sudo pptpconfig
После чего перед глазами появляется следующее окно (рис. 3).
В соответствующие поля формы вбиваем имя туннеля (то есть соединения - в моем случае оно могло быть произвольным набором символов), IP'адрес VPN-сервера (говорят, что можно и его внутрисетевое имя, но у меня это не сработало), полученные от провайдера логин и пароль (поле Domain остается пустым).
Откуда взялся адрес VPN-сервера? Ведь, как вы помните, провайдер оставил мне в конвертике только его внутрисетевое имя. Определит адрес по URL можно различными путями, я воспользовался командой
$ host труляля.ok
каковая и выдала мне искомый IP'шник.
Заполнив таким образом форму Server, я, в соответствие с инструкциями, перешел на закладку Encryption, где, вместо отмеченного по умолчанию пункта MPPE, включил пункт, говорящий про EAP (рис. 4).
Теперь остается только кнопкой Add добавить новосозданный туннель в список и, отметив его курсором, нажать кнопку Start для проверки. Нажатие ее приводит к открытию нового окна (рис. 5), в котором проверку можно выполнить посредством кнопки Ping.
К моей радости, пинги с новым внутренним сервером прошли успешно. Более того, команда
$ ifconfig -a
показала наличие интерфейса ppp0 (никуда теперь не исчезающего) с новыми параметрами - моим IP-адресом (прежний, для eth0, начинался со 192, этот же - со 172), адресом P-t-P (он, собственно, и пинговался при тесте) и новой маской подсети.
Теперь, в соответствие с инструкцией, оставалось последнее действие: сделать только что созданный канал доступным для программ. Для этого останавливаю соединение (кнопкой Stop в любом из двух окон) и в окне настройки перехожу на вкладку Routing, включаю в ней пункт All to Tunnel вместо умолчального Client to Lan (рис. 6) и кнопкой Start активизирую туннель заново. Теоретически после этого можно, например, выйти в Интернет любым браузером.
В этот момент радость моя и закончилась. Попытки открыть какой-либо сайт успехом не увенчались. Пинги не проходили ни на один внешний URL. Более того, и внутрисетевые URL'ы пинговаться перестали.
Так и пребывал бы я в растерянности, если бы не советы знакомых админов - пропинговать внешние сервера не по URL, а по IP-адресам. И - о чудо - пинги пошли. Стало ясно, что дело в настройках DNS. просмотр файла /etc/resolv.conf показал, что вместо прежних их адресов появились новые - совершенно мифического облика. Ничтоже сумняшеся, я вписываю туда IP своего служебного DNS-сервера. После чего наконец обретаю выход в Интернет.
Теперь у меня вроде все нормально - но получать имена со стороны не есть правильно с точки зрения быстродействия. Надо найти способ сделать это внутренними силами сети провайдера. Благо, в окне настройки pptpconfig для этого имеется соответствующая закладка - DNS, в которой по умолчанию сервера имен определяются автоматически (рис. 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, смысл, думаю, понятен без перевода).
Решения первой задачи я пока не нашел. Вследствие особенностей дистрибутивов Kununtu (отсутствия root-аккаунта как такового) со стандартными средствами типа запуска от имени другого пользователя, у меня ничего не вышло. Придется думать дальше. Ну и если кто подскажет - буду весьма признателен.
Какой вывод можно сделать из моей истории? Перефразируя слова Александра Дюма, заключаю: не следует верить ни тому, что говорят провайдеры, ни тому, что говорят их враги. Соединение VPN в Linux наладить вполне можно. Нужно только, если это не получается с первой же попытки, затратить некоторое время на перебор вариантов. Используя прямые IP, не полагаясь на данные, полученные при подключении.
Я понимаю, что все описанное выше способно вызвать у профессионального сетевика лишь ироническую улыбку. Однако как пользовательское решение оно вполне работает - и для меня (а также, подозреваю, большинства обычных пользователей) это главное.
Кстати говоря, описанный метод настройки VPN - далеко не единственный. Прошерстив через
$ apt-cache search vpn
репозитории Ubuntu (с чего, собственно, и нужно было бы начать по хорошему, если бы не нетерпеливое вожделение Сети), я обнаружил несколько VPN-клиентов и немало front-end'ов для них, например - kvpnc, предназначенный, как явствует из имени, специально для KDE. И, следовательно, более подходящий для использования в Kubuntu. Возможно, что с какими-то из этих программ результата можно было бы добиться быстрее и проще. Впрочем, этот вопрос я надеюсь исследовать и описать в ближайшее время.
Автор выражает признательность Игорю Борейко, системному администратору , и Стену, админу сайта , за ценные советы и моральную поддержку.
