CITKIT.ru - свободные мысли о свободном софте
Деловая газета CitCity.ru Библиотека CITForum.ru Форумы Курилка
Каталог софта Движение Open Source Дискуссионный клуб Дистрибутивы Окружение Приложения Заметки Разное
06.04.2020

Последние комментарии

ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)
24 December, 22:53
Kubuntu Feisty (15)
24 December, 18:42
Один на один с Windows XP (3758)
24 December, 11:46

Каталог софта

Desktop
Internet
Internet-серверы
Безопасность
Бизнес/Офис
Игры
Мультимедиа
Наука
Операционные системы
Программирование
СУБД
Создание веб-сайтов
Утилиты

Статьи

Дискуссионный клуб
Linux в школе
Open Source и деньги
Open Source и жизнь
Windows vs Linux
Копирайт
Кто такие анонимусы
Лицензии
Нетбуки
Нужен ли русский Linux?
Пользователи
Дистрибутивы
Идеология
Выбор дистрибутива
Archlinux & CRUX
Debian
Fedora
Gentoo
LFS
LiveCD
Mandriva
OpenSolaris
Slackware
Zenwalk
Другие линуксы
BSD
MINIX
Движение Open Source
История
Классика жанра
Окружение
shell
Библиотеки UI
Графические среды
Шрифты
Приложения
Безопасность
Управление пакетами
Разное
Linuxformat. Колонки Алексея Федорчука
Заметки
Блогометки
Файловые системы
Заметки о ядре

Заметки

Linux: приключения с VPN микрорайонного масштаба

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

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

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

И вот тут я и наткнулся на предложение микрорайонного масштаба, показавшееся мне весьма привлекательным: бесплатное подключение, безлимитный тариф - 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 руками. Обратившись по началу к напрашивающемуся варианту - скриптовому запуску. И надо заметить, что скриптов для этого дела в сети можно раскопать немало. Например, решение, претендующее на универсальность, описано на POSIX.ru. Вариант для 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).

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

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

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

$ host труляля.ok

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

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

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

Теперь остается только кнопкой 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-сервера провайдера (с моим служебным сервером имен это прошло нормально). Если бы не одно но: для этого адрес этот хорошо бы знать.

Рис. 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. Возможно, что с какими-то из этих программ результата можно было бы добиться быстрее и проще. Впрочем, этот вопрос я надеюсь исследовать и описать в ближайшее время.

Автор выражает признательность Игорю Борейко, системному администратору Геологического института РАН, и Стену, админу сайта http://posix.ru, за ценные советы и моральную поддержку.




Комментарии

Страницы комментариев: 1 :: 2 :: следующая

Алексей Федорчук, Wed Nov 7 14:05:20 2007:
2 Дедушка Фрэйд
Увы - настройка VPN зависит не от дистра, а исключительно от радиуса кривизны рук провайдера.
Сколько я ни сталкивался с этим угробищем - двух одинаковых настроек так встретить и не довелось.
Где-то на Линуксфоруме создали коллективными усилиями универсальный хаутуй на эту тему - поглядите в разделе Проекты форума, м.б. чем подсобит.
Дедушка Фрэйд, Wed Nov 7 13:40:08 2007:
Алексей Федорчук

У меня к вам просьбочка: перейдите на мандриву, желательно, 2007 Spring и по ней такой же мануальчег :)
А то у меня с ВПН вообще труба какая то :)
Алексей Федорчук, Tue Nov 6 20:57:26 2007:
2 собан
сидите на винде пока, ныне, присно. и во веки веков
нафиг нам такой геморрой - 1001-й вопрос про настройку VPN на 102-м форуме?
аноним, Tue Nov 6 20:22:43 2007:
скажите мне как простому пользователю зачем такой геморой нужен я лучше пока на винде посижу впрочем как большинство народа
Eggog, Mon Apr 30 15:41:41 2007:
А вот интересно.Возможно в Линуксе использовать L2TP IPSec vpn-соединение?
salas, Thu Mar 29 00:46:58 2007:
>нормальное оборудование

А "нормальное" железо в каждый дом ставить, ну, скажем, на 20 абонентов - не слишком дорого окажется при московских тарифах?
аноним, Wed Mar 28 00:15:10 2007:
to salas
есть если ставить нормальное оборудование на дома, а не хабы из загашника дедушки
salas, Sat Mar 24 02:31:19 2007:
2 аноним, пятница, 23 марта 2007 г. 08:27:15

>Сколько-нибудь серьезный провайдер в первопрестольной ныне не грузит клиентов VPN соединением, предпочитая привязку по MAC адресу.

А защита от хацкеров, выставляющих на сетевухе соседский MAC, пока сосед спит, при этом есть?
alv, Fri Mar 23 10:44:04 2007:
2 аноним, пятница, 23 марта 2007 г. 08:27:15
Точно с провайдером не угадали, но близко.
Только на счет 3-го эшелона про него сказать - это польстить :)
> Сколько-нибудь серьезный провайдер в первопрестольной ныне не грузит клиентов VPN соединением, предпочитая привязку по MAC адресу.
__
Ох не скажите... Корбина, насколько я знаю, до сих пор этим балуется.
alv, Fri Mar 23 10:41:49 2007:
2 GhostDragon
Все верно, надо. Только мне внутренняя локалка практически была без надобности, а когдая это случайно обнаружил, то уже и провайдера пора было менять :)

Страницы комментариев: 1 :: 2 :: следующая

Комментарии заморожены.

Новости:

Все новости на CitCity.ru

Компании месяца

 
Последние комментарии
Почему школам следует использовать только свободные программы (101)
20 Декабрь, 14:51
ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)

24 Декабрь, 22:53
Linux в школе: мифы про школу и информатику (334)
24 Декабрь, 22:43
Kubuntu Feisty (15)
24 Декабрь, 18:42
Software is like sex: it's better when it's free.
©Linus Torvalds