Перевод и обработка: Сгибнев Михаил
Примечание: оригинал документа находится здесь:
http://www.netbsd.org/Documentation/network/pppoe/,
в документе очень много лишнего, что и было убрано.
Поддержка в ядре
Необходимо убедиться, что 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
Теперь нам понадобятся наши аутентификационные данные.
Введем их воспользовавшись следующей командой (учтите, что для закрытия специальных символов используются одинарные кавычки):
pppoectl pppoe0 myauthproto=pap 'myauthname=XXX' 'myauthsecret=YYY' hisauthproto=none
В данном случае, XXX это имя пользователя, а YYY - его пароль.
Параметр hisauthproto=none указывает PPP, что нет необходимости подтверждать подлинность провайдера, так как
большинство из них не предоставляют такой возможности.
Если провайдер осуществляет авторизацию по протоколу CHAP, то необходимо установить параметр myauthproto=chap.
Мы готовы к подключению. Так как что-то может пойти неправильно, мы ограничим количество повторных попыток установить
соединение:
pppoectl pppoe0 max-auth-failure=1
И активируем интерфейс:
ifconfig pppoe0 up
Поскольку мы не задействовали режим отладки, то на консоли мы не увидим ровным счетом ничего.
Работу сессии PPPoE мы можем проверить следующим образом:
# pppoectl -d pppoe0
pppoe0: state = session
Session ID: 0x254f
PADI retries: 0
PADR retries: 0
В этом примере у нас отображается рабочая сессия PPPoE (state = session).
Если у вас указано другое состояние, то проверьте правильность указания регистрационных данных или
доступность сервера. Ошибки будут отображаться как увеличение значения счетчиков PADI или PADR.
Попробуйте указать service name (через опцию -s в pppoectl)
или access concentrator name (через опцию -a в pppoectl), если эти данные необходимы, то провайдер
должен вам их предоставить.
Для получения дополнительной информации, обратитесь к странице руководства man
pppoectl(8).
После того как сессия PPPoE была установлена, проверим правильность выделения IP адреса сервисом PPP:
# ifconfig pppoe0
pppoe0: flags=8851 mtu 1492
inet 117.80.111.85 -> 118.5.113.169 netmask 0xff000000
Как мы видим, подключение установлено правильно, поскольку мы видим свой адрес и адрес удаленного хоста
(естесственно, у вас будут другие адреса). Если вы не видите подобной картины, то скорее всего, вы неверно
указали аутентификационные данные 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:
#! /bin/sh
/sbin/route add default $5
/etc/rc.d/ntpd restart
/etc/rc.d/named restart
Соединение по требованию
В данном примере мы устанавливаем соединение при необходимости передать данные и разрываем его при простое.
Главные отличия от постоянного соединения заключаются в следующем:
- Флаг 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 необходимо указать
следущие строки:
map pppoe0 192.168.1.0/24 -> 0/32 portmap tcp/udp 44000:49999 mssclamp 1440
map pppoe0 192.168.1.0/24 -> 0/32 mssclamp 1440
Если вы не используете NAT, то добавьте такое правило:
map pppoe0 x.x.x.x/24 -> 0/0 mssclamp 1440
В вышеприведенных примерах MTU принимается равным 1492 байтам.
Учитывая смещение в 52 байта, укажите свое MTU, например 1408 для MTU 1460 байта.
Обратите внимание: теоретически правильное значение для вышеупомянутого примера было бы 1452 байта
(минимальное значение PPPoE MTU, заголовок TCP и максимум 0x40 байтов опций TCP).
Примечание переводчика: я плохо понял смысл этого абзаца, если есть возможность - отпишите в форум.
The above examples assume a MTU of 1492 bytes. If the MTU on your PPPoE connection is smaller use the MTU -
52 bytes for clamping e.g. 1408 bytes for a MTU of 1460 bytes. Note: The theoretically correct value for
the above example would be 1452 bytes (it accounts for the smaller PPPoE MTU, the TCP header and the
maximum of 0x40 bytes of TCP options) but it seems to not be sufficient in some cases. Experiments
conducted by various people have shown that clamping to the MSS values suggested above works best.