Направление через связь PPP
После установки сетевого interface, pppd будет устанавливать хост маршрут только к своему peer. Если remote хост находится на LAN, Вы обязательно захотите быть способным соединится с хостами множествами "позади" Вашего peer; то есть сетевой маршрут должен быть установлен.
Мы уже видели, что pppd можно попросить уствновить заданный по умолчанию маршрут, используяю опцию defaultroute. Эта опция очень полезна если PPP сервер, с которым Вы связались будет действовать как ваши Internet ворота.
Обратный случай, где ваша система действует как ворота для единственного хоста, является также относительно простым для того, чтобы быть выполненым. Например, возьмите некоторых служащих в Virtual Brewery, чья локальная машина называется loner. При соединении с vlager через PPP, он использует адрес на подсети Brewery. В vlager, мы можем теперь дать pppd опцию proxyarp, которая установит полномочную ARP запись для loner. Это автоматически сделает loner доступным для всех и в Winery.
Однако, вещи далеко не всегда просты как это иногда кажется, например когда Вы соединяете две LAN. Это обычно требует добавления специального сетевого маршрута, потому что эти сети могут иметь свой маршрут заданный по умолчанию. Кроме того, имея обоих peer использование связи PPP как маршрут заданный по умолчанию генерировало бы цикл, где блоки к некзвеутным адресатам будут пинаться между peer пока их time-to-live истечет.
Как пример, предположите, что Virtual Brewery открывает ветвь в каком-нибудь другом городе. Подразделение запускает собственную Ethernet используя IP сетевой номер 191.72.3.0, который является подсетью 3 из Brewery класса B сети. Они хотят соединиться с Brewery's main Ethernet via PPP для тго, чтобы модифицировать базы данных заказчиков, и т.д. Снова, vlager действует как ворота; peer вызывается sub-etha и имеет адрес IP 191.72.3.1..
Когда sub-etha соединится с vlager, она примет заданный по умолчанию маршрут к vlager как обычный. На vlager, мы будем должны установить сетевой маршрут для подсети 3, который проходит к sub-etha. Для этого, мы используем особенность pppd, не обсужденного пока - ip-в готовности команды. Это shell script или программа, размещенная в /etc/ppp, которая выполнена после того, как PPP interface был сконфигурирован. Когда он существует, это вызывается со следующими пар
ip- up iface device speed local addr remote addr
Где iface называет сетевой interface используемым, device - тропа файла последовательного устройства используемого (/dev/tty, если stdin/stdout используется), и speed - быстродействие устройства. Local addr и remote addr дают IP адреса, используемые в обоих концах связи в dotted quad notation. В нашем случае, ip-up script, может содержать следующий кодовый фрагмент:
#!/bin/sh case $5 in 191.72.3.1) # this is sub-etha route add -net 191.72.3.0 gw 191.72.3.1;; esac exit 0
В подобном режиме, /etc/ppp/ip-down используется для того, чтобы отменить все действия ip-up после того, как связь PPP была демонтирована снова.
Однако, схемж матшрутов еще не полна. Мы установили маршрут входов таблицы на оба PPP хоста, но пока, все другие хосты на обих сетях не знают ничего относительно связи PPP. Это не большая проблема, если все хосты в подразделении имеют свои, заданные по умолчанию маршруты в sub- etha, и все хосты в Brewery направляются к vlager по умолчанию. Если это не так, то ваша единственная опция будет использовать daemon маршрут подобно воротам. После создания сетевого маршрута передал бы по радио новый маршрут ко всем хостам на присоединенной подсети.
