Давно известно, что в сетях некоторых провайдеров, есть проблемы с поднятием VPN из под FreeBSD.
Пару лет назад наткнулся на эту проблему в своей сети, не стал долго думать и поставил железный роутер и был доволен. Но, как известно, человек предполагает, а инет располагает. В общем назрела эта проблема вновь. Гугление выдает великое множество ссылок на различные рецепты шаманских танцев с бубном и без оного, но мне не удалось найти ни одного нормального описания приводящего к желаемому результату. Однако поднять VPN-туннель у меня получилось :)
На самом деле, все элементарно.
На FeeBSD 6.2 с mpd4-4.0b4 все поднимается на ура.
Необходимо убедиться, что PPPoE поддерживается ядром. Для этого выполните команду:
-bash-3.00$ ifconfig -C
bridge vlan gif gre tun tap strip sl pppoe ppp lo
Если в строке вывода не обнаружится упоминания о pppoe, то необходимо перекомпилировать ядро, добавив туда строку:
pseudo-device pppoe
Проверка соединения
Прежде чем настраивать на машине автоматическое соединение, давайте попробуем все сделать в ручном режиме. В случае проблем это позволит нам быстро обнаружить и устранить неисправность.
Сначала мы создаем интерфейс pppoe и назначаем ему произвольный адрес, так как в дальнейшем он будет изменен в ходе установления сессии PPP. Поскольку интерфейс еще не настроен, активировать его не будем.
ifconfig pppoe0 create
ifconfig pppoe0 inet 0.0.0.0 0.0.0.1 down
Сейчас привяжем интерфейс pppoe к соответствующей сетевой карте, например к той, к которой подключен DSL модем, или которая смотрит в сеть провайдера.
ifconfig rtk0 up
pppoectl -e rtk0 pppoe0
Теперь нам понадобятся наши аутентификационные данные. Введем их воспользовавшись следующей командой (учтите, что для закрытия специальных символов используются одинарные кавычки):
В данном случае, XXX это имя пользователя, а YYY – его пароль. Параметр hisauthproto=none указывает PPP, что нет необходимости подтверждать подлинность провайдера, так как большинство из них не предоставляют такой возможности. Если провайдер осуществляет авторизацию по протоколу CHAP, то необходимо установить параметр myauthproto=chap.
Мы готовы к подключению. Так как что-то может пойти неправильно, мы ограничим количество повторных попыток установить соединение:
pppoectl pppoe0 max-auth-failure=1
И активируем интерфейс:
ifconfig pppoe0 up
Поскольку мы не задействовали режим отладки, то на консоли мы не увидим ровным счетом ничего. Работу сессии PPPoE мы можем проверить следующим образом:
В этом примере у нас отображается рабочая сессия PPPoE (state = session). Если у вас указано другое состояние, то проверьте правильность указания регистрационных данных или доступность сервера. Ошибки будут отображаться как увеличение значения счетчиков PADI или PADR. Попробуйте указать service name (через опцию -s в pppoectl) или access concentrator name (через опцию -a в pppoectl), если эти данные необходимы, то провайдер должен вам их предоставить. Для получения дополнительной информации, обратитесь к странице руководства man pppoectl(8).
После того как сессия PPPoE была установлена, проверим правильность выделения IP адреса сервисом PPP:
Как мы видим, подключение установлено правильно, поскольку мы видим свой адрес и адрес удаленного хоста (естесственно, у вас будут другие адреса). Если вы не видите подобной картины, то скорее всего, вы неверно указали аутентификационные данные PPP.
Установка постоянного соединения
После того, как мы проверили работу соединения, настроим машину на автоматическую установку сессии.
Для этого нам придется написать несколько сценариев и внести изменение в некоторые файлы конфигурации. В зависимости от тарифного плана, вы можете предпочесть постоянное соединение или соединение по требованию.
Независимо от тарифного плана, провайдер должен вам предоставить адреса DNS серверов, которые необходимо внести в /etc/resolv.conf.
Постоянное соединение
В этом случае мы устанавливаем соединение и оставляем его открытым сколь угодно долго, восстанавливая связь при обрыве.
Создадим файл /etc/ifconfig.pppoe0 следующего содержания:
create
# Mark the physical interface used by this PPPoE interface up
! /sbin/ifconfig rtk0 up
# Let $int use rtk0 as its Ethernet interface
! /sbin/pppoectl -e rtk0 $int
# Configure authentication
! /sbin/pppoectl $int myauthproto=pap 'myauthname=XXX' 'myauthsecret=YYY' hisauthproto=none
# Configure the PPPoE interface itself. These addresses are magic
# meaning we don't care about either address and let the remote
# ppp choose them.
0.0.0.0 0.0.0.1 up
Выставьте права доступа таким образом, чтобы прочитать этот файл мог только пользователь root.
В файл /etc/ppp/ip-up внесите:
#! /bin/sh
/sbin/route add default $5
В файл /etc/ppp/ip-down внесите:
#! /bin/sh
/sbin/route delete default $5
Также убедитесь, что прочитать эти файлы может только пользователь root.
В заключение, добавим следущую строку в /etc/rc.conf:
ifwatchd=YES
Дело сделано. Обратите внимание, что загружается демон ifwatchd (выполняющий сценарии ip-up и ip-down). Проблема может заключаться в том, что маршрут по умолчанию может быть установлен после старта сетевых демонов, что приведет к некорректной их работе. Для устранения этой досадной ошибки рекомендую использовать подобный сценарий ip-up:
В данном примере мы устанавливаем соединение при необходимости передать данные и разрываем его при простое.
Главные отличия от постоянного соединения заключаются в следующем:
Флаг link1 на интерфейсе pppoe0
Лимит бездействия (в данном примере 60 секунд)
Конфигурация маршрутизации, когда первый пакет идет на интерфейс pppoe0, в то время, как соединение еще не установлено
Создадим файл /etc/ifconfig.pppoe0:
create
# Mark the physical interface used by this PPPoE interface up
! /sbin/ifconfig ne0 up
# Let $int use ne0 as its Ethernet interface
! /sbin/pppoectl -e ne0 $int
# Configure authentication
! /sbin/pppoectl $int idle-timeout=60 myauthproto=pap 'myauthname=XXX' 'myauthsecret=YYY' hisauthproto=none
# Configure the PPPoE interface itself. These addresses are magic
# meaning we don't care about either address and let the remote
# ppp choose them.
0.0.0.0 0.0.0.1 link1 up
! /sbin/route add default -iface 0.0.0.1
Использовать ifwatchd в этой конфигурации нет необходимости, поскольку мы уже задаем маршрут по умолчанию. Если вам необходимо получать уведомления о изменениях IP адресов или состояния соединения, то вы можете сконфигурировать ifwatchd и использовать/etc/ppp/ip-up и/etc/ppp/ip-down.
Установка NAT с MSS-clamping
Некоторые машины с ненастроенной системой фильтрации пакетов пытаются использовать Path-MTU-Discovery, в то время как пакетный фильтр отбрасывает все ICMP пакеты. Вполне вероятно, что вам придется общаться с такими системами, при необходимости получить от них данные.
В связи с этим, предать большие обьемы данных машине, подключенной через PPPoE, будет затруднительно. Для решения этого вопроса мы пошлем маленькое значение MSS (maximum segment size) во время установки сессии TCP. Для этого нам необходимо установить sysctl переменную net.inet.tcp.mss_ifmtu, добавив в /etc/sysctl.conf следущую строку:
# Obey interface MTUs when calculating MSS
net.inet.tcp.mss_ifmtu=1
В этом случае, в правилах NAT вашего маршрутизатора, имеющего связь с миром через PPPoE необходимо указать следущие строки:
Если вы не используете NAT, то добавьте такое правило:
map pppoe0 x.x.x.x/24 -> 0/0 mssclamp 1440
В вышеприведенных примерах MTU принимается равным 1492 байтам. Учитывая смещение в 52 байта, укажите свое MTU, например 1408 для MTU 1460 байта. Обратите внимание: теоретически правильное значение для вышеупомянутого примера было бы 1452 байта (минимальное значение PPPoE MTU, заголовок TCP и максимум 0×40 байтов опций TCP).
Аббревиатура CARP расшифровывается как Common Address Redundancy Protocol. Основной целью этого протокола является использование одного IP адреса в пределах одного сегмента сети несколькими машинами. CARP является свободной, безопасной альтернативой протоколам Virtual Router Redundancy Protocol и Hot Standby Router Protocol.
CARP позволяет выделить группу хостов в сегменте сети и назначить ей один IP адрес. Такая группа называется «redundancy group» (группа избыточности). В пределах этой группы, один из хостов становится «главным», а остальные обозначаются как «резервные». В каждый момент времени мастер-хост отвечает на ARP-запросы к назначенному IP адресу и обрабатывает трафик, идущий к этому адресу. Каждый хост одновременно может принадлежать к нескольким группам.
Одним распространенным случаем использования CARP является создание избыточности на брандмауэрах. Виртуальный IP, который назначен на группу избыточности, указан на клиентских машинах в качестве шлюза по умолчанию. В случае отказа брандмауэра, выполняющего роль мастера, резервный брандмауэр возмет этот IP адрес и продолжит обслуживание клиентов.
При использовании CARP снижаются требования к аппаратному обеспечению отказоустойчивых систем. Дорогое оборудование окажется бессильным к выдернутому шнуру питания или перед администратором, случайно отправившим сервер в перезагрузку. CARP также облегчает процесс обновления программного обеспечения, так цикл обновления и перезагрузки прозрачен для пользователей, становится проще и процесс тестирования программного или аппаратного обеспечения – вы всегда можете положиться на резерв, пока не устраните проблему.
Однако, есть ситуации, когда CARP не может помочь. Дизайн CARP требует, чтобы члены одной группы физически находились в одной подсети с одним статическим IP адресом, хотя с введением директивы carpdev необходимости назначать адрес на физический интерфейс нет. Сервисы, требующие постоянного соединения с сервером (такие как SSH и IRC) не могут быть прозрачно переброшены в случае отказа и потребуют переподключения. CARP не может синхронизировать данные между приложениями.
Архитектура i386 содержит в себе массу функций, призваных обеспечить совместимость со старыми машинами, вплоть до серии 8086. С технической точки зрения, в этом нет необходимости, так как любой современный компьютер, основанный на этой архитектуре использует полностью 32-разрядную операционную систему, которая могла работать и без кода, обеспечивающего обратную совместимость. К сожалению, требования к совместимости остаются и тормозят развитие нового программного обеспечения.
Одной из деталей, которая не изменялась в течение многих лет является процесс загрузки i386. Спроектирован он был в дни, когда компьютеры имели накопители на гибких магнитных дисках и небольшое firmware. С тех пор процедура не перенесла никакого изменения, что делает некоторые задачи очень сложными. Одна из них – загрузка нескольких операционных систем на одной машине.
Новое firmware для Intel-based машин, Extensible Firmware Interface (EFI) решает эту проблему, обеспечивая более универсальный процесс загрузки. Другие архитектуры уже предоставляют улучшенные firmware с более хорошими механизмами загрузки, включая, например, способность загрузки и выполнения ELF обряза прямо из кода инициализации машины. Так обстоит дело с OpenFirmware в Macintosh PowerPC.
