Алексей Федорчук
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-серверов.
Рис. 1. Выбор сетевого интерфейса…
Рис. 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).
В соответствующие поля формы вбиваем имя туннеля (то есть соединения — в моем случае оно могло быть произвольным набором символов), IP’адрес VPN-сервера (говорят, что можно и его внутрисетевое имя, но у меня это не сработало), полученные от провайдера логин и пароль (поле Domain остается пустым).
Откуда взялся адрес VPN-сервера? Ведь, как вы помните, провайдер оставил мне в конвертике только его внутрисетевое имя. Определит адрес по URL можно различными путями, я воспользовался командой
$ host труляля.ok
каковая и выдала мне искомый IP’шник.
Заполнив таким образом форму Server, я, в соответствие с инструкциями, перешел на закладку Encryption, где, вместо отмеченного по умолчанию пункта MPPE, включил пункт, говорящий про EAP (рис. 4).
Теперь остается только кнопкой Add добавить новосозданный туннель в список и, отметив его курсором, нажать кнопку Start для проверки. Нажатие ее приводит к открытию нового окна (рис. 5), в котором проверку можно выполнить посредством кнопки Ping.
Рис. 5. Окно статуса соединения VPN
К моей радости, пинги с новым внутренним сервером прошли успешно. Более того, команда
$ ifconfig -a
показала наличие интерфейса ppp0 (никуда теперь не исчезающего) с новыми параметрами — моим IP-адресом (прежний, для eth0, начинался со 192, этот же — со 172), адресом P-t-P (он, собственно, и пинговался при тесте) и новой маской подсети.
Теперь, в соответствие с инструкцией, оставалось последнее действие: сделать только что созданный канал доступным для программ. Для этого останавливаю соединение (кнопкой Stop в любом из двух окон) и в окне настройки перехожу на вкладку Routing, включаю в ней пункт All to Tunnel вместо умолчального Client to Lan (рис. 6) и кнопкой Start активизирую туннель заново. Теоретически после этого можно, например, выйти в Интернет любым браузером.
Рис. 6. Делаем канал доступным
В этот момент радость моя и закончилась. Попытки открыть какой-либо сайт успехом не увенчались. Пинги не проходили ни на один внешний 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, смысл, думаю, понятен без перевода).
Рис. 8. Запуск туннеля одновременно с запуском pptpconfig
Решения первой задачи я пока не нашел. Вследствие особенностей дистрибутивов Kununtu (отсутствия root-аккаунта как такового) со стандартными средствами типа запуска от имени другого пользователя, у меня ничего не вышло. Придется думать дальше. Ну и если кто подскажет — буду весьма признателен.
Какой вывод можно сделать из моей истории? Перефразируя слова Александра Дюма, заключаю: не следует верить ни тому, что говорят провайдеры, ни тому, что говорят их враги. Соединение VPN в Linux наладить вполне можно. Нужно только, если это не получается с первой же попытки, затратить некоторое время на перебор вариантов. Используя прямые IP, не полагаясь на данные, полученные при подключении.
Я понимаю, что все описанное выше способно вызвать у профессионального сетевика лишь ироническую улыбку. Однако как пользовательское решение оно вполне работает — и для меня (а также, подозреваю, большинства обычных пользователей) это главное.
Кстати говоря, описанный метод настройки VPN — далеко не единственный. Прошерстив через
$ apt-cache search vpn
репозитории Ubuntu (с чего, собственно, и нужно было бы начать по хорошему, если бы не нетерпеливое вожделение Сети), я обнаружил несколько VPN-клиентов и немало front-end’ов для них, например — kvpnc, предназначенный, как явствует из имени, специально для KDE. И, следовательно, более подходящий для использования в Kubuntu. Возможно, что с какими-то из этих программ результата можно было бы добиться быстрее и проще. Впрочем, этот вопрос я надеюсь исследовать и описать в ближайшее время.
При настройке своего многострадального соединения автор пользовался постоянной поддержкой Игоря Борейко, бессменного админа куста контор моей бывшей службы. Игоря позвали верхние люди. Светлая память…
Ситуация знакомая — ток в моем случае она была еще более запутанная:
vpn устанавливалась не на прямую к провайдеру — а через шлюз представлющий из себя кабельный модем (настроенный провайдером не прозрачно а с физическим ip аддресом). В результате для подключения к vpn требовалось кинуть маршрут по умолчанию к модему, а после подключения к впн этот маршрут заменялся на маршрут по умолчанию забранным автоматически при соединении — соответсвенно впн обваливался. Если не давать срабатывать автоматическому выставлению маршрута, то тогда не работал инет … так как маршрут продолжал смотреть на шлюз — а не по ту сторону впн ….. Решалось все на редкость просто, — к модему создавался не default gateway а статический маршрут, тогда при соединении спокойно создавался default маршрут через впн, без потери связи с модемом — и инет в этой системме работал нормально.
п.с: для меня это было не концом бед — в нашем мухосранске (астрахани) комуникации не менялись со времен революции (ну не дошла до нас отечественная война) и потому связь вечно падала уволакивая за собой с таким трудом поднятый впн :) . Потому пришлось ставить еще сторожащий ppp0 скрипт прикрученный к cron, который проверял каждую минуту наличие этого интерфейса в системме — и при отсутсвии поднимавший падшего. Подобных сторожей с тех пор ставлю всегда потому что беда с комуникациями касается любой связи любых провайдеров нашего города (даже оптоволокно нп работе)