Направление через связь 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 маршрут   подобно  воротам. После создания сетевого маршрута передал бы по радио   новый маршрут ко  всем хостам на  присоединенной подсети.