Protokol PPP slouží, stejně jako protokol SLIP, k posílání datagramů po sériové lince, avšak odstraňuje spoustu nedostatků, kterými trpí protokol SLIP. Umožňuje, aby si komunikující strany na počátku spojení dohodly parametry spojení, kterými mohou být například IP-adresa nebo maximální velikost datagramu. Dále poskytuje protokol PPP možnost ověření totožnosti klienta. Pro každou z těchto vlastností má protokol PPP samostatný protokol. V této kapitole si tyto základní stavební prvky protokolu PPP popíšeme. Kapitola však zdaleka neposkytuje veškeré informace; chcete-li se toho dozvědět o protokolu PPP více, měli byste si přečíst jeho specifikaci v RFC 1548 a dále přibližně tucet doprovodných RFC.
Na nejnižší hladině protokolu PPP se nachází tzv. Vysokoúrovňový protokol pro řízení datového spojení (High-Level Data Link Control Protocol), zkráceně HDLC, který definuje pole jednotlivých rámců protokolu PPP a poskytuje 16bitový kontrolní součet. Na rozdíl od primitivnějšího zapouzdření v protokolu SLIP může rámec v protokolu PPP obsahovat pakety i jiných protokolů, než IP, například protokolu IPX sítě Novell nebo protokolu Appletalk. Této vlastnosti je v protokolu PPP dosaženo tak, že k základnímu rámci protokolu HDLC je přidáno speciální protokolové pole, které identifikuje typ paketu přenášeného daným rámcem.
Protokol LCP, neboli protokol pro řízení spojení (Link Control Protocol), se používá nad protokolem HDLC a používá se ke sjednávání parametrů týkajících se datového spojení, jako je například maximální příjmová jednotka (Maximum Receive Unit - MRU), jež uvádí maximální velikost datagramu, kterou je jedna ze stran ochotná přijímat.
Důležitým krokem ve fázi konfigurace spojení pomocí protokolu PPP je ověření totožnosti klienta. Ačkoliv není povinné, je u většiny linek nabízejících připojení pomocí modemu de facto nezbytné. Volaný hostitel (server) obvykle vyzve klienta k ověření své totožnosti za pomocí nějakého tajného klíče. Není-li volající schopen poskytnout správný tajný klíč, bude spojení ukončeno. U protokolu PPP funguje ověřování totožnosti oběma směry; to znamená, že i klient může požádat server, aby prokázal svou totožnost. Obě tyto ověřovací procedury jsou na sobě vzájemně nezávislé. Pro účely těchto dvou různých způsobů ověřování jsou k dispozici dva protokoly, o kterých se ještě zmíníme. Nazývají se protokol pro ověření hesla (Password Authentication Protocol), zkráceně PAP, a protokol na ověření inicializační výzvy (Challenge Handshake Authentication Protocol - CHAP).
Každý Síťový protokol, který je směrován po datové lince, například protokoly IP, AppleTalk atd., je konfigurován dynamicky za pomoci odpovídajícího protokolu pro řízení sítě (Network Control Protocol - NCP). Například při posílání IP-datagramu po lince si musí nejprve oba hostitelé s protokolem PPP dohodnout, jakou IP-adresu bude každý z nich používat. Řídicím protokolem, který se k tomuto účelu používá, je protokol IPCP, neboli protokol na řízení internetového protokolu (Internet Protocol Control Protocol).
Kromě vlastního posílání IP-datagramů po lince podporuje protokol PPP také Van Jacobsonovu kompresi hlaviček IP-datagramů. To je technika používaná ke zmenýování velikosti hlaviček TCP-paketů až na tři bajty. Tato technika se používá také v protokolu CSLIP a obecně je známá pod názvem VJ komprese hlaviček. I použití komprese může být sjednáno při spuštění pomocí protokolu IPCP.
V Linuxu je funkce protokolu rozdělena na dvě části, na vysokoúrovňový ovladač HDLC, který se nachází v jádru operačního systému, a na démona uživatelského prostoru pppd, který se stará o různé řídicí protokoly.
Ovladač protokolu PPP v jádru operačního systému napsal Michael Callahan. Démon pppd byl odvozen z volně šiřitelné implementace protokolu PPP v počítačích Sun a 386BSD, jehož autorem je Drew Perkins a kol. a nyní jej spravuje Paul Mackerras. Na platformu Linuxu ho převedl Al Longyear.
Program chat napsal Karl Fox.
Protokol PPP je, stejně jako protokol SLIP, implementován pomocí speciálního režimu linky. Chcete-li používat nějakou sériovou linku jako linku s protokolem PPP, musíte nejprve obvyklým způsobem vytvořit spojení pomocí modemu a následně převést linku do režimu protokolu PPP. V tomto režimu budou všechna příchozí data podstoupena ovladači protokolu PPP, který ověří platnost rámců protokolu HDLC (každý rámec HDLC je doplněn 16bitovým kontrolním součtem), rozbalí je a odešle. V současné době je schopen spravovat IP-datagramy, volitelně i použití Van Jacobsonovy komprese hlaviček. Jakmile bude Linux podporovat i protokol IPX, dojde i k rozšíření ovladače PPP o správu IPX paketů.
Ovladači jádra operačního systému pomáhá démon pppd, což je démon protokolu PPP, který provádí veškerou inicializační fázi a fázi ověřování totožnosti, což je nutné před zahájením provozu po příslušné lince. Chování démona pppd je možné doladit pomocí mnoha parametrů. Jelikož je ovladač protokolu PPP poměrně složitý, není možné popsat všechny tyto parametry v jediné kapitole.
Tato kniha tak nepokrývá všechny aspekty démona pppd, poskytuje jen stručný úvod. Chcete-li se o tomto problému dozvědět více, nahlédněte do manuálu a do souborů README, které jsou součástí distribuce zdrojového kódu démona pppd, a tam byste měli nalézt většinu dotazů, jež nejsou součástí této kapitoly. Pokud budete mít problémy i po přečtení těchto materiálů, obrašte se na konferenci comp.protocols.ppp, která sdružuje většinu lidí zainteresovaných na vývoji démona pppd.
Když se chcete připojit na Internet pomocí protokolu PPP, musíte nejdříve nastavit základní Síťovou podporu, jako je zpětnovazebné zařízení a resolver. Oba druhy Síťové podpory byly probírány v předchozích kapitolách. S použitím systému DNS souvisí ještě některé věci, o kterých je třeba se zmínit; najdete je v kapitole věnované protokolu SLIP.
V úvodním příkladu, který se bude zabývat navázáním spojení PPP pomocí démona pppd, předpokládáme, že jste opět na hostiteli vlager. Již jste vytočili server PPP s názvem c3po a přihlásili jste se na účet ppp. Server c3po již aktivoval svůj ovladač protokolu PPP. Po ukončení komunikačního programu, který jste použili k vytočení čísla serveru, spustíte následující příkaz:
# pppd /dev/cua3 38400 crtscts defaultroute
Tento příkaz přepne sériovou linku cua3 do režimu PPP a naváže IP-spojení se serverem c3po. Přenosová rychlost použitá sériovým portem bude 38 400 bps. Parametr crtscts zapíná na daném portu hardwarové řízení toku dat, které u rychlostí nad 9 600 bps musí být rozhodně zapnuto.
Démon pppd si ihned po spuštění domluví některé charakteristiky se svým protějšekem.
K tomu použije protokol LCP. Při sjednávání charakteristik budou obvykle fungovat implicitní parametry, takže se jimi zde nemusíme dále zabývat. V další kapitole se na protokol LCP podíváme detailněji.
Budeme také předpokládat, že server c3po od nás nebude vyžadovat žádný typ ověřování totožnosti, čímž máme konfigurační fázi úspěšně za sebou.
Následně domluví démon pppd se svým protějýkem parametry IP, k čemuž použije protokol IPCP, což je protokol řídící IP. Protože jsme démonu pppd nepředali žádnou konkrétní IP-adresu, pokusí se ji získat tak, že nechá resolver vyhledat místní název hostitele. Potom si oba hostitelé sdělí své IP-adresy.
Tato implicitní nastavení jsou zpravidla dostačující. Dokonce i v případě, že je váš počítač připojen do sítě Ethernet, můžete použít stejnou IP-adresu jak pro Ethernet, tak i pro rozhraní PPP. Přesto vám démon pppd dovolí použít odlišnou adresu, případně může požádat váš protějšek, aby použil nějakou konkrétní adresu. Tyto volby jsou rozebírány dále.
Po úspěšném dokončení fáze nastavení protokolu IPCP připraví démon pppd Síťovou vrstvu, která se bude používat při spojení pomocí protokolu PPP. Nejprve nastaví Síťové rozhraní PPP jako spojení typu point-to-point, a to tak, že pro první aktivní spojení pomocí protokolu PPP použije rozhraní ppp0, pro druhé aktivní spojení ppp1 atd. Dále nastaví položku ve směrovací tabulce, která bude odkazovat na hostitele na druhém konci spojení. V dříve zmíněném příkladu nastaví démon pppd implicitní směr na server c3po, protože mu byla přiřazena volba defaultroute.Tato volba způsobí, že všechny datagramy poslané hostitelům, kteří se nenacházejí ve vaší místní síti, budou poslány na server c3po. Démon pppd podporuje velké množství směrovacích schémat. Ty budou detailněji probrány dále v této kapitole.
Dříve, než démon pppd analyzuje argumenty příkazové řádky, projde několik souborů, zda neobsahují implicitní volby. Tyto soubory mohou obsahovat libovolné argumenty příkazové řádky, jež mohou být uvedeny na několika řádkách. Komentáře jsou uvozeny symbolem křížku.
Prvním souborem voleb je soubor s názvem /etc/ppp/options, který se při spuštění démona pppd vždy prohlíží. Je dobré využít tohoto souboru ke specifikaci některých globálních implicitních nastavení, čímž zabráníte vašim uživatelům v nechtěném poškození bezpečnosti celého systému. Chcete-li například, aby démon pppd vyžadoval od svého protějýku nějaký typ ověření totožnosti (bui pomocí protokolu PAP, nebo pomocí protokolu CHAP), uveite v tomto souboru volbu auth. Tuto volbu nemůže uživatel potlačit, takže nemůže navázat spojení pomocí protokolu PPP s žádným systémem, který není v ověřovací databázi.
Druhým souborem voleb, který se čte po souboru /etc/ppp/options, je soubor .ppprc. Nachází se v domovském adresáři příslušného uživatele. Každý uživatel tak může specifikovat svoji vlastní množinu implicitních voleb. Vzorový soubor /etc/ppp/options by mohl vypadat asi takto:
# Globální volby pro pppd běžící na vlager.vbrew.com
auth # požaduj autorizaci
usehostname # pro CHAP použij lokální jméno
lock # používej zamykání UUCP
domain vbrew.com # naše doména
První dvě volby se vztahují k procesu ověřování totožnosti a budou vysvětleny dále. Klíčové slovo lock nastaví démona pppd tak, aby vyhovoval standardní metodě UUCP, která definuje blokování zařízení. Podle tohoto standardu vytvoří každý proces, který přistupuje k sériovému zařízení, konkrétně k zařízení /dev/cua3, v dočasném adresáři UUCP zamykající soubor s názvem LCK..cua3, jehož přítomnost bude signalizovat, že je dané zařízení momentálně využíváno. To proto, aby jiné programy, například minicom nebo uucico, nemohly otevřít sériové zařízení v okamžiku, kdy ho používá protokol PPP.
Důvodem začlenění těchto voleb do globálního konfiguračního souboru je skutečnost, že uživatel nemůže Výše uvedené volby potlačit a ty tím pádem poskytují solidní úroveň zabezpečení. Všimněte si však, že některé volby potlačit lze; příkladem budiž řetězec connect.
Jednou z věcí, která se vám mohla zdát v předchozím příkladu nepohodlná, je nutnost manuálně navázat spojení dříve, než se spustí démon pppd. Na rozdíl od nástroje dip nemá démon pppd svůj vlastní skriptový jazyk, který by umožňoval vytočení a přihlášení ke vzdálenému systému. Místo toho spoléhá na nějaký externí program nebo skript příkazového interpretu, který za něj tento úkol provede. Příkaz, který se má provést, lze předat démonu pppd pomocí volby příkazové řádky connect. Démon pppd přesměruje standardní vstup a výstup příkazu na sériovou linku. Pro tento účel existuje jeden užitečný program s názvem expect, jehož autorem je Don Libes. Obsahuje výkonný jazyk vycházející z jazyka Tcl, který byl navržen přesně pro tento druh aplikace.
Balík pppd obsahuje podobný program s názvem chat, který umožňuje zadat komunikační skript ve stylu UUCP. Komunikační skript je v podstatě složen ze střídající se sekvence očekávaných řetězců, které přijdou ze vzdáleného systému a z odpovědí, jež posíláme. Následuje typický výpis z komunikačního skriptu:
ogin: b1ff ssword: s3kr3t
Tento příkaz říká programu chat, aby vyčkal, dokud vzdálený systém nepošle výzvu k přihlášení, a potom mu poslal přihlašovací jméno b1ff. Čekáme pouze na řetězec ogin:, takže nebude vadit, když bude přihlašovací výzva začínat malým nebo velkým písmenem l, nebo když dorazí ve zkomolené formě. Následující řetězec je opět očekávaný řetězec, který pozdrží program chat, dokud nepřijde výzva k zadání hesla, potom odešle naše heslo jako odpověď.
To je v podstatě hlavní účel komunikačních skriptů. Kompletní skript sloužící k vytáčení serveru PPP by musel samozřejmě obsahovat patřičné příkazy pro modem. Předpokládejme, že váš modem rozumí množině příkazů standardu Hayes a že telefonní číslo vytáčeného serveru je 318 714. Kompletní vyvolání programu chat, které by provedlo spojení se serverem c3po, by potom vypadalo následovně:
$ chat -v ‚‚ ATZ OK ATDT318714 CONNECT ‚‚
ogin: ppp word: GaGariN
Podle definice musí být první řetězec očekávaný řetězec, ale protože nám modem nic neodpoví, dokud ho nepobídneme, musíme sdělit programu chat, aby první očekávaný řetězec přeskočil. Provedeme to tak, že tento řetězec zadáme jako prázdný řetězec. Pak pokračujeme odesláním příkazu ATZ, což je inicializační řetězec pro modemy kompatibilní se standardem Hayes a následně budeme čekat na odpověď (OK). Následující řetězec pošle vytáčecí program programu chat společně s telefonním číslem a jako odpověď očekává zprávu CONNECT.
Za ní opět následuje prázdný řetězec. Protože v tuto chvíli nechceme nic posílat, čekáme spíše na výzvu k přihlášení. Zbytek komunikačního skriptu funguje naprosto shodně s výše popsaným postupem.
Parametr -v zajistí, že program chat bude veškeré aktivity zapisovat do souboru.
Zadávání komunikačního skriptu na příkazové řádce s sebou nese jistá rizika, protože si uživatelé mohou prohlédnout příkazovou řádku daného procesu pomocí příkazu ps. Tomuto problému se vyhnete, když umístíte komunikační skript do souboru, řekněmě dial-c3po. Pomocí parametru -f, za kterým následuje název souboru, sdělíte programu chat, aby četl skript ze souboru místo z příkazové řádky. Kompletní spuštění démona pppd by mohlo nyní vypadat následovně:
# pppd connect iochat -f dial-c3pol_
/dev/cua3/ 38400 -detach \ crtscts modem defaultroute
Kromě volby connect specifikující skript pro vytáčení jsme do příkazové řádky přidali ještě další dvě volby: -detach sdělí démonu pppd, aby se odpojil od konzoly a jako proces se přepnul na pozadí. Klíčové slovo modem sděluje démonu pppd, aby na sériovém zařízení provedl některé akce specifické pro modem, jako je zavěšení linky před a po volání. Pokud toto klíčové slovo nepoužijete, nebude démon pppd monitorovat linku DCD na sériovém portu, a proto nebude schopen detekovat neočekávané zavěšení na vzdálené straně.
Výše uvedené příklady byly poměrně jednoduché; program chat však umožňuje psát mnohem složitější komunikační skripty. Jednou z užitečných vlastností je určení řetězce, při kterém se komunikační skript zastaví s chybou. Typickými řetězci pro zastavení běhu skriptu jsou zprávy jako BUSY nebo NO CARRIER, které generuje váš modem v případě, že je volané číslo obsazené nebo vzdálená strana nezvedá telefon. Aby program chat rozpoznal tyto zprávy okamžitě, ne až po uplynutí určité doby, můžete je zadat na začátku skriptu pomocí klíčového slova ABORT:
$ chat -v ABORT BUSY ABORT ‚NO CARRIER‚ ‚‚ ATZ OK ...
Podobným způsobem můžete ve skriptu změnit hodnotu čekací doby pomocí volby TIMEOUT. Podrobnosti získáte na stránkách manuálu programu chat(8).
Někdy budete také potřebovat určitý druh podmíněného spouštění jednotlivých částí komunikačního skriptu. Když například neobdržíte od vzdáleného konce výzvu pro přihlášení, budete chtít poslat příkaz BREAK nebo znak návrat vozíku (CR). Toho docílíte přidáním podřetězce k očekávanému řetězci. Ten se bude skládat ze sekvence posílaných a očekávaných řetězců, stejně jako tomu bylo v celém skriptu. Tyto řetězce jsou odděleny znakem pomlčka.
Podřetězec je spuštěn vždy, když očekávaný řetězec, ke kterému se daný podřetězec vztahuje, není přijat v zadaném čase. V níže uvedeném příkladu upravíme komunikační řetězec následujícím způsobem:
ogin:-BREAK-ogin: ppp ssword: GaGariN
Když program chat neuvidí výzvu pro přihlášení, která by měla přijít ze vzdáleného konce, spustí podřetězec, který nejdříve pošle příkaz BREAK a potom bude čekat na opětovnou výzvu pro přihlášení. Pokud se nyní tato výzva objeví, bude skript pokračovat běžným způsobem, v opačném případě skončí s chybou.
Démon pppd bude implicitně zapisovat veškeré varování a chybové zprávy do souboru syslog démona. Do souboru syslog.conf musíte přidat položku, která toto zapisování přesměruje do souboru, případně na konzolu, v opačném případě prostředky syslog tyto zprávy zruší. Následující položka způsobí, že budou všechny zprávy posílány do souboru
/var/log/ppp-log:
daemon.* /var/log/ppp-log
Jestliže vaše nastavení nefunguje ihned, můžete na základě tohoto log-souboru poskytnout první indiciš o tom, co je v nepořádku. Pokud vám ani to nepomůže, můžete také pomocí volby debug zapnout speciální ladicí výstup. Tato volba nařídí démonu pppd, aby zapisoval do prostředků syslog obsahy všech poslaných nebo přijatých řídicích paketů.
Konečně nejdrastičtějším způsobem je povolení ladicích informací na úrovni jádra operačního systému. To je možné provést spuštěním démona pppd s volbou kdebug. Za touto volbou následuje číselný argument, který je bitově orientovanou operací OR nad následujícími hodnotami: 1 pro obecné ladicí informace, 2 pro vytištění obsahu všech příchozích rámců protokolu HDLC a při hodnotě 4 vypíše ovladač veškeré odcházející rámce protokolu HDLC.
Abyste mohli zachytávat ladicí zprávy jádra operačního systému, musíte buď spustit démona syslogd, který čte soubor /proc/kmsg nebo démona klogd. Oba tito démoni směrují ladící informace jádra do souboru syslog.
Protokol IPCP slouží k dohodnutí několika parametrů IP v době konfigurace spojení. Každá z komunikujících stran může poslat paket s požadavky na konfiguraci protokolu IPCP (IPCP Configuration Reguest), který obsahuje informace o implicitních hodnotách, jež se mají změnit a jaké mají být jejich hodnoty. Po přijetí tohoto paketu prozkoumá vzdálený konec střídavě každou z těchto voleb a buď ji přijme, nebo ji odmítne.
Démon pppd vám dává k dispozici velký prostor pro řízení parametrů protokolu IPCP, které se bude snažit dohodnout. Tyto parametry můžete nastavovat pomocí různých voleb příkazové řádky, které probereme později.
V předchozím příkladu nám démon pppd vytočil server c3po a navázal spojení IP. Nebyla provedeny žádná opatření, která by některému z obou konců přidělila konkrétní IP-adresu.
Místo toho jsme použili adresu hostitele vlager jako místní IP-adresu a serveru c3po jsme ponechali jeho vlastní IP-adresu. Někdy je však užitečné mít kontrolu nad tím, která adresa bude použita na jednom nebo druhého konci spojení. Démon pppd poskytuje několik typů takovéto kontroly.
Chcete-li si vyžádat konkrétní adresy, stačí démonu pppd předat následující volbu:
local_addr:remote_addr
Parametry local_addr a remote_addr mohou být zapsány buď ve formě tečkové notace, nebo jako názvy hostitelů.
Tento příkaz způsobí, že se démon pppd pokusí použít první adresu jako svou vlastní IP-adresu a druhou adresu jako IP-adresu protějýku. Pokud protějšek v průběhu sjednávání parametrů pomocí protokolu IPCP některou z těchto adres odmítne, nedojde k řádnému spojení IP.
Pokud chcete nastavit pouze místní adresu a přitom hodláte akceptovat libovolnou adresu protějýku, ponechte část remote_addr volnou. Chcete-li například, aby server vlager používal místo své vlastní IP-adresy adresu 130.83.4.27, měli byste na příkazové řádce zadat 130.83.4.27:. Podobně chcete-li nastavit pouze adresu vzdáleného počítače, ponechte volné pole local_addr. Démon pppd pak použije adresu sdruženou s názvem vašeho hostitele.
Některé servery PPP, které obsluhují velké množství klientů, přidělují IP-adresy dynamicky: adresy jsou systému přiděleny pouze v okamžiku volání a ihned po jeho odhlášení jsou opět uvolněny. Spojujete-li se s takovýmto typem serveru, musíte se ujistit, že démon pppd nevyžaduje od serveru žádnou konkrétní IP-adresu, ale přijme adresu, kterou po vás server požaduje. To znamená, že nemůžete použít argument local_addr. Kromě toho musíte použít volbu noipdefault, která sdělí démonu pppd, aby nepoužil místní adresu hostitele, ale počkal na přidělení IP-adresy od protějšího počítače.
Jakmile je nastaveno Síťové rozhraní, nastaví obvykle démon pouze hostitelské směrování ke svému protějýku. Je-li vzdálený hostitel v síti LAN, budete se jistě chtít spojit také s hostiteli, kteří jsou "za hranicemišé vašeho protějýku; to znamená, že musí být nastaveno směrování sítí.
Už jsme si ukázali, že démona pppd je možné za pomoci volby defaultroute požádat, aby nastavil implicitní směr. Tato volba je velmi užitečná v případě, že se vámi vytočený server PPP bude chovat jako internetová brána.
Realizace obráceného případu, kdy se váš systém chová pro konkrétního hostitele jako brána, je také poměrně jednoduchá. Vězměte si například několik zaměstnanců ze společnosti Virtual Brewery, jejichž domovský počítač má název loner. Když se takový zaměstnanec spojí s hostitelem vlager pomocí protokolu PPP, použije ke spojení adresu podsítě virtuálního pivovaru. Na bráně vlager můžeme nyní použít volbu proxyarp, která nainstaluje pro hostitele loner proxy ARP. Takto bude hostitel loner automaticky dostupný ze všech hostitelů, kteří se nacházejí v síti pivovaru nebo vinárny.
Ne vždy to ale jde tak jednoduše, jako v tomto případě, příkladem budiž spojení dvou lokálních sítí. To obvykle vyžaduje přidání konkrétního Síťového směrování, protože tyto sítě již mohou mít své vlastní implicitní směry. Kromě toho, když necháte u obou protějýků nastaven implicitní směr na spojení pomocí protokolu PPP, vznikne smyčka, ve které budou mezi oběma protějýky obíhat pakety určené pro neznámé lokace tak dlouho, dokud nevyprší jejich doba přežití (TTL).
Jako příklad předpokládejme, že si společnost Virtual Brewery otevře pobočku v nějakém jiném městě. Tato pobočka bude mít svůj vlastní Ethernet, který bude používat IP-adresu 191.72.3.0, což je podSíť 3 v síti pivovaru. Síť pivovaru je třídy B. Lidé z pobočky se chtějí spojit s hlavním Ethernetem pivovaru pomocí spojení PPP, aby si mohli aktualizovat databáze zákazníků atd. Hostitel vlager se opět chová jako brána; jeho protějšek se nazývá sub-etha a má přidělenu IP-adresu 191.72.3.1.
Když se hostitel sub-etha spojí s hostitelem vlager, nastaví jako obvykle implicitní směr na hostitele vlager. Nicméně na bráně vlager musíme nainstalovat Síťové směrování pro podSíť 3, které bude ukazovat na hostitele sub-etha. K tomuto účelu použijeme ještě neprobranou vlastnost démona pppd - příkaz ip-up. Jedná se o skript příkazovéko interpretu nebo program umístěný v adresáři /etc/ppp, který je spouštěn po konfiguraci rozhraní PPP. Je-li tento program přítomný, spustí se s následujícími parametry:
ip-up iface device speed local_addr remote_addr
Argument iface označuje používané Síťové rozhraní, parametr device představuje cestu k používanému sériovému zařízení (jsou-li použity parametry stdin/stdout, bude tato cesta ukazovat do souboru /dev/tty) a parametr speed představuje rychlost daného zařízení.
Parametry local_addr a remote_addr předávají IP-adresy, které použijí oba počítače účastnící se spojení. Tyto adresy jsou uvedeny v tečkové notaci. V našem příkladu by měl skript ip-up obsahovat následující část kódu:
#!/bin/sh
case $5 in
191.72.3.1) # to je sub-etha
route add -net 191.72.3.0 gw 191.72.3.1;;
esac
exit 0
Jakmile je spojení pomocí protokolu PPP ukončeno, je podobným způsobem použit skript /etc/ppp/ip-down, který vrátí zpět všechny akce provedené skriptem ip-up.
Nicméně směrovací schéma ještě není kompletní. Na obou hostitelích s protokolem PPP jsme nastavili položky směrovací tabulky, avšak žádný z hostitelů obou sítí dosud neví nic o existujícím spojení pomocí protokolu PPP. To nebude problém v případě, že mají všichni hostitelé v pobočce vinárny nastaveno svůj implicitní směr na hostitele sub-etha a všichni hostitelé v síti pivovaru mají nastaven implicitní směrování na bránu vlager. Není-li to váš případ, budete zřejmě nuceni použít nějakého směrovacího démona, například démona gated. Jakmile na bráně vlager vytvoříte Síťové směrování, bude směrovací démon vysílat nové směrování všem hostitelům, kteří jsou připojeni k podsítím.
V předcházejících statích jsme se setkali s protokolem LCP (Protokol na řízení spojení), který je používán pro sjednávání charakteristik spojení a k testování spojení.
Dvě nejdůležitější volby, jež mohou být sjednávány pomocí protokolu LCP, jsou maximální příjmová jednotka (MRU) a asynchronní řídicí mapa znaků (Asynchronous Control Character Map). Existuje i spousta dalších voleb, které je možné pomocí tohoto protokolu nastavovat, ty jsou však příliš specializované na to, abychom se zde jimi mohli zabývat. Jejich případný popis najdete v RFC 1548.
Asynchronní řídicí mapa znaků, které se hovorově říká asynchronní mapa, slouží u asynchronních spojení, jako jsou telefonní linky, k identifikaci řídicích znaků, které musí být vynechány (musí být nahrazeny konkrétní sekvencí dvou znaků). Měli byste se například vyvarovat použití znaků XON a XOFF, které jsou používány k softwarovému řízení toku dat a ýpatně nakonfigurovaný modem by se mohl při přijetí takového znaku zablokovat. Dalším kandidátem je kombinace kláves Ctrl+] (znak pro ukončení telnetu). Protokol PPP umožňuje vynechat libovolné znaky s ASCII kódy od 0 do 31, pokud jsou uvedeny v asynchronní mapě.
Asynchronní mapa je bitová mapa o šířce 32 bitů, kde nejnižší platný bit odpovídá ASCII znaku NUL a nejvyšší platný bit odpovídá ASCII znaku s hodnotou 31. Je-li příslušný bit nastaven, znamená to, že odpovídající znak musí být před odesláním po lince vynechán. Implicitně je asynchronní mapa nastavena na hodnotu 0xffffffff, to znamená, že budou všechny řídicí znaky vynechány.
Chcete-li sdělit vašemu protějýku, že nemusí přeskakovat všechny řídicí znaky, ale jen některé z nich, můžete zadat novou asynchronní mapu, kterou předáte démonu pppd pomocí volby asyncmap. Mají-li se přeskočit pouze znaky ^S a ^Q (znaky s ASCII hodnotou 17 a 19, které se obecně používají pro řízení XON a XOFF), použijte následující volbu:
asyncmap 0x000A0000
Maximální příjmová jednotka neboli MRU signalizuje protějýku, jakou maximální velikost rámců protokolu HDLC chceme používat. I když vám to možná připomíná hodnotu MTU (maximální přenosová jednotka), nemají spolu tyto dvě hodnoty téměř nic společného.
Hodnota MTU je parametrem pro Síťové zařízení jádra operačního systému a popisuje maximální velikost rámce, o kterou se může příslušné rozhraní starat. Hodnota MRU říká vzdálenému konci, že nemá generovat rámce větší než je hodnota MRU; rozhraní však musí být bez ohledu na tuto skutečnost schopno přijmout rámečky až do velikosti 1 500 bajtů.
Volba hodnoty MRU proto není ani tak otázkou toho, co je daná linka schopna přenést, jako spíše otázkou nastavení, se kterým dosáhnete nejvyššího výkonu. Pokud hodláte po příslušném spojení provozovat interaktivní aplikace, pak je dobré nastavit hodnotu MRU přinejmenším na hodnotu 296 bajtů, aby nějaký větší paket (konkrétně například paket z relace FTP) nezpůsobil "skokio vašeho kurzoru. Chcete-li démonu pppd sdělit, že hodláte používat MRU o velikosti 296 bajtů, měli byste mu tuto hodnotu předat pomocí parametru mru 296. Nicméně malé hodnoty MRU mají smysl pouze v případě, že nemáte zakázánu VJ kompresi hlaviček (implicitně je povolena).
Démon pppd rozumí také některým volbám protokolu LCP, které nastavují celkové chování procesu sjednávání parametrů, jako je maximální počet konfiguračních požadavků, které si mohou obě strany vyměnit, než se spojení ukončí. Dokud si nebudete absolutně jisti tím, co děláte, neměli byste tyto parametry měnit.
Kromě toho existují ještě dvě volby týkající se opakování echo zpráv protokolu LCP. Protokol PPP definuje dvě zprávy, opakování požadavku (Echo Request) a opakování odpovědi (Echo Response). Démon pppd používá tuto vlastnost ke kontrole funkčnosti spojení. Tuto vlastnost můžete povolit za pomoci volby lcp-echo-interval, za kterou následuje časový údaj v sekundách. Pokud nebudou v tomto intervalu ze vzdáleného hostitele přijaty žádné rámečky, vygeneruje démon pppd zprávu Echo Request a bude očekávat, že mu protějšek vrátí hlášku Echo Response. Jestliže se tak nestane, pak se spojení po určitém počtu odeslaných požadavků ukončí. Tento počet je možné nastavit pomocí volby lcp-echo-failure. Implicitně je tato volba zakázána.
Špatně nakonfigurovaný démon protokolu PPP může mít z hlediska bezpečnosti zhoubný vliv na celý systém. V nejhorším případě to vypadá tak, že má každý uživatel možnost připojení do vaší sítě Ethernet (a to je velice špatné). V této stati si povíme o několika málo opatřeních, které by měly zabezpečit vaši konfiguraci protokolu PPP.
Jedním z problémů démona pppd je to, že pro konfiguraci Síťových zařízení a směrovací tabulky vyžaduje přístupová práva superuživatele. To obvykle vyřešíte tak, že ho necháte běžet setuid root. Nicméně démon pppd dovoluje uživatelům nastavovat z hlediska bezpečnosti různě významné volby. Abyste se chránili před útoky, které může uživatel spustit při manipulaci s těmito volbami, doporučuje se nastavit několik implicitních hodnot do souboru /etc/ppp/options, například ty, které jsme použili v ukázkovém souboru v sekci Použití souboru options. Některé z nich, například volby pro ověření totožnosti, nemůže uživatel potlačit, a proto poskytují dostatečnou ochranu před zneužitím.
Samozřejmě, že se musíte chránit i ze strany systémů, se kterými provozujete spojení na bázi protokolu PPP. Abyste se chránili před hostiteli, kteří se vydávají za někoho jiného, měli byste při komunikaci s protějýkem vždy používat nějaký druh ověření totožnosti. Kromě toho byste měli cizím hostitelům zakázat používání IP-adres dle vlastního výběru a omezit jejich výběr jen na několik málo IP-adres. V následující stati se budeme zabývat právě těmito tématy.
Pokud systém používá protokol PPP, může požadovat po svém protějýku, aby dokázal svoji totožnost pomocí jednoho ze dvou protokolů sloužících k ověřování totožnosti. Jsou to protokol pro ověření hesla (Password Authentication Protocol - PAP) a protokol pro ověření inicializační výzvy (Challenge Handshake Authentication Protocol - CHAP). Po navázání spojení může každá strana žádat po svém protějýku, aby dokázal svoji totožnost, bez ohledu na to, zda jde o volajícího nebo o volaného. V dalším výkladu budu v případech, kdy bude nutné, rozlišovat mezi ověřovaným systémem a ověřovatelem neurčité pojmy "klient" a "server". Démon protokolu PPP může požádat svůj protějšek, aby dokázal svoji totožnost. To provede tak, že pomocí protokolu LCP pošle další konfigurační požadavek, v němž bude uveden požadovaný ověřovací protokol.
Protokol PAP pracuje v podstatě stejně jako klasická přihlašovací procedura. Klient ověří svoji totožnost tak, že serveru pošle jméno uživatele a (volitelně zašifrované) heslo, tato data server porovná se svou vlastní tajnou databází. Tuto techniku mohou obejít tzv. naslouchači, kteří se snaží získat potřebná hesla tak, že odposlouchávají sériovou linku a potom provádějí útoky systémem pokus omyl.
Protokol CHAP takové nedostatky nemá. Ověřovatel (tj. server) pošle klientovi náhodně vygenerovaný řetězec s "výzvoušn a spolu s ním i svůj název hostitele. Klient na základě názvu hostitele vyhledá příslušné tajné informace, zkombinuje je s přijatou výzvou a zašifruje tento řetězec pomocí jednosměrné šifrovací funkce. Výsledek pak společně s názvem hostitele klienta pošle zpět serveru. Server pak provede stejné výpočty a dojde-li k témuž výsledku, povolí klientovi přístup.
Další vlastností protokolu CHAP je, že nevyžaduje po klientovi ověření jeho totožnosti jen při spuštění, ale posílá výzvy v pravidelných intervalech, aby se ujistil, že klienta nenahradil nějaký vetřelec, například přepnutím telefonních linek.
Démon pppd implicitně nevyžaduje po svém protějýku ověření totožnosti, ale souhlasí se svým vlastním ověřením totožnosti v případě, že je o to vzdáleným počítačem požádán. Protože je protokol CHAP mnohem výkonnijší než protokol PAP, snaží se ho démon pppd používat, kdykoliv jen je to možné. Pokud ho protějšek nepodporuje nebo pokud démon pppd nemůže pro vzdálený systém nalézt v souboru chap-secrets tajné informace protokolu CHAP, pak démon přepne na protokol PAP. Nenajde-li tajné informace pro svůj protějšek ani v protokolu PAP, odmítne prokázat svoji totožnost. V důsledku toho dojde k ukončení spojení.
Toto chování se může upravit několika způsoby. Použijete-li například klíčové slovo auth, bude démon pppd požadovat po svém protějýku, aby prokázal svou totožnost. Pro tento účel bude démon souhlasit s použitím protokolu CHAP nebo protokolu PAP, má-li ve své databázi CHAP, resp. PAP uloženy tajné informace pro svůj protějšek. Existují i další volby, kterými je možno zapnout nebo vypnout konkrétní protokol pro ověření totožnosti, avšak ty zde nebudeme rozebírat. Chcete-li o nich více podrobností, nahlédněte prosím do manuálové stránky démona pppd(8).
Budou-li všechny systémy, se kterými máte spojení pomocí protokolu PPP, souhlasit s ověřením své totožnosti, měli byste vložit volbu auth do globálního souboru /etc/ppp/options a pro každý systém definovat v souboru chap-secrets příslušná hesla. Pokud daný systém protokol CHAP nepodporuje, vložte záznam o tomto systému do souboru pap-secrets. Pak si můžete být jisti, že se žádný neověřený systém k vašemu hostiteli nepřipojí.
Následující dvě stati budou probírat tajné soubory protokolu PPP, konkrétně soubory pap-secrets a chap-secrets. Najdete je v adresáři /etc/ppp a obsahují trojici klientů, serverů a hesel, volitelně následované seznamem IP-adres. Interpretace polí klienta a serveru je u protokolu CHAP jiná, než u protokolu PAP a závisí také na tom, zda dokazujeme svoji totožnost našemu protějýku, nebo zda požadujeme po serveru, aby nám svoji totožnost prokázal on.
Když musíte nějakému serveru dokázat svoji totožnost pomocí protokolu CHAP, vyhledá démon pppd v souboru chap-secrets položku, která má pole klienta totožné s polem názvu místního hostitele a pole serveru bude mít totožné s názvem vzdáleného hostitele, který byl doručen pomocí výzvy protokolu CHAP. Když požadujete po protějýku, aby dokázal svoji totožnost, budou role obrácené: démon pppd vyhledá položku, u které se pole klienta shoduje s názvem vzdáleného hostitele (který je zaslán v odpovědi protokolu CHAP) a pole serveru je shodné s názvem místního hostitele.
Následuje vzorový soubor chap-secrets pro bránu vlager:
# Soubor CHAP secrets pro vlager.vbrew.com
#
# klient server tajemství adresa
#------------------------------------------------------------------
vlager.vbrew.com c3po.lucas.com "Use The Source" vlager.vbrew.com
c3po.lucas.com vlager.vbrew.com "riverrun, pasteve" c3po.lucas.com
* vlager.vbrew.com "VeryStupidPassword" pub.vbrew.com
Při spojení pomocí protokolu PPP s hostitelem c3po požádá hostitel c3po bránu vlager, aby mu dokázala svoji totožnost pomocí protokolu CHAP. Brána to provede tak, že pošle výzvu protokolu CHAP. Poté démon pppd vyhledá v souboru chap-secrets položku, která má pole klienta shodné s adresou vlager.vbrew.com a její pole serveru se shoduje s adresou c3po.lucas.com; 10 v našem příkladu to bude položka na prvním řádku. Pak vytvoří démon pppd z řetězce obsahujícího výzvu a z tajných informací (Use The Source) odpověď pro protokol CHAP a pošle ji hostiteli c3po.
Ve stejném okamžiku sestaví démon pppd výzvu protokolu CHAP určenou pro hostitele c3po, která bude obsahovat jedinečný řetězec s výzvou společně s plně kvalifikovaným názvem hostitele vlager.vbrew.com. Hostitel c3po vytvoří Výše popsaným způsobem odpověď pro protokol CHAP a tuto odpověď vrátí zpět bráně vlager. Nyní démon pppd vyjme z odpovědi hostitelský název klienta (c3po.vbrew.com) a vyhledá v souboru chap-secrets řádek, v němž klientovi odpovídá hostitel c3po a serveru pak hostitel vlager. Této podmínce vyhovuje druhý řádek, takže démon pppd zkombinuje výzvu protokolu CHAP s tajnou informací riverrun, pasteve, zašifruje je a výsledek porovná s odpovědí protokolu CHAP, která přišla od hostitele c3po.
Volitelné čtvrté pole obsahuje seznam IP-adres, které jsou přijatelné pro klienty uvedené v prvním poli. Adresy mohou být zadány v tečkové notaci nebo jako názvy hostitelů, které vyhledá resolver. Požaduje-li například hostitel c3po během sjednávání spojení pomocí protokolu IPCP IP-adresu, která není uvedena v tomto seznamu, bude požadavek zamítnut a protokol IPCP bude ukončen. Proto je ve Výše uvedeném vzorovém souboru hostitel c3po omezen pouze na použití své vlastní IP-adresy. Je-li pole s adresami prázdné, budou povoleny libovolné adresy; pokud je zde znak "-", nemůže daný klient použít žádnou IP-adresu.
Třetí řádek ve vzorovém souboru chap-secrets povoluje libovolnému hostiteli navázat spojení pomocí protokolu PPP s bránou vlager, protože hodnota * u pole klienta nebo serveru odpovídá libovolnému názvu hostitele. Jediným požadavkem na spojení je, že klient musí znát tajné informace a musí používat adresu pub.vbrew.com. Položky se zástupnými znaky představující názvy hostitelů se mohou v souboru s tajnými informacemi objevit kdekoliv, protože démon pppd bude vždy používat nejkonkrétnější položku, která se vztahuje k danému páru polí server/klient.
Dále bychom měli říci něco o způsobu, jakým démon pppd dospěje k názvům hostitelů v souboru tajných informací. Jak jsme si již dříve vysvětlili, název vzdáleného hostitele dodá vždy protějšek v paketu výzvy protokolu CHAP nebo v paketu odpovědi protokolu CHAP.
Místní název hostitele bude implicitně odvozen z volání funkce gethostname(2). Pokud jste nastavili název systému jako nekvalifikovaný název hostitele, pak musíte démonu pppd poskytnout název domény pomocí volby domain:
# pppd ...domain vbrew.com
Tato volba připojí k hostiteli vlager název domény pivovaru u všech aktivit, které se vztahují k ověřování totožnosti. Dalšími volbami, které upravují představu démona pppd o názvu místního hostitele, jsou volby usehostname a name. Když na příkazovou řádku zadáte místní IP-adresu pomocí volby "local:varremotei., kde parametr local je název hostitele místo adresy respektující tečkovou notaci, použije démon pppd tento zápis jako název místního hostitele. Více podrobností najdete na manuálové stránce pppd(8).
Soubor s tajnými informacemi protokolu PAP je velmi podobný souboru, který využívá protokol CHAP. První dvě pole vždy obsahují jméno uživatele a název serveru; třetí pole obsahuje tajné informace protokolu PAP. Když vzdálený počítač pošle požadavek na ověření totožnosti, použije démon pppd položku, která má pole server shodné s názvem místního hostitele a pole se jménem uživatele má shodné se jménem uživatele, které je posláno v žádosti.
V době, kdy démon pppd dokazuje svému protějýku svoji totožnost, vybere démon pppd ze souboru tajných informací tu položku, u níž se pole se jménem uživatele shoduje s místním uživatelským jménem a pole serveru se shoduje s názvem vzdáleného hostitele. Potom tyto tajné informace odešle.
Vzorový soubor tajných informací protokolu PAP může vypadat asi takto:
# /etc/ppp/pap-secrets
#
# uživatel server heslo adresa
vlager-pap c3po cresspahl vlager.vbrew.com
c3po vlager DonaldGNUth c3po.lucas.com
První řádek používáme při rozhovoru s hostitelem c3po. Druhý řádek popisuje, jak nám může uživatel se jménem c3po dokázat svoji totožnost.
Název vlager-pap ve sloupci jedna představuje jméno uživatele, které pošleme hostiteli c3po.
Démon pppd vezme implicitně název místního hostitele jako uživatelské jméno, ale pomocí volby user můžete také zadat jiné jméno uživatele. Při výběru položky ze souboru pap-secrets musí démon pppd znát název vzdáleného hostitele. Protože neexistuje žádný způsob, jak by ho mohl zjistit, musíte mu ho předat na příkazové rádce pomocí volby remotename, za níž následuje název hostitele vašeho protějšku.
Například, abychom mohli používat Výše uvedenou položku pro dokázání naší totožnosti hostiteli c3po, musíme na příkazovou řádku démona pppd doplnit následující volbu:
# pppd ... remotename c3po user vlager-pap
Ve čtvrtém poli (a ve všech následujících polích) můžete zadat, jaké adresy může daný hostitel používat, je to stejné jako u souboru s tajnými informacemi protokolu CHAP. Protějšek pak může požadovat adresy pouze z tohoto seznamu. Ve vzorovém příkladu požadujeme, aby hostitel c3po používal svou skutečnou IP-adresu.
Všimněte si, že protokol PAP představuje poměrně slabou metodu na ověření totožnosti a proto se doporučuje, kdykoliv je to možné, používat místo něj protokol CHAP. Z toho důvodu zde nebudeme detailněji rozebírat protokol PAP. Popis některých dalších vlastností protokolu PAP najdete na manuálové stránce pppd(8).
Spuštění démona pppd jako serveru je pouze otázkou doplnění příslušných voleb do příkazové řádky. Teoreticky je nutné vytvořit speciální účet, konkrétně účet ppp, přidělit mu nějaký skript nebo program, který bude fungovat jako přihlašovací příkazový interpret, jenž spustí démona pppd s těmito volbami. Do souboru /etc/passwd byste mohli například přidat následující řádek:
ppp:*:500:200:Public PPP Account:/tmp:/etc/ppp/ppplogin
Je možné, že budete chtít používat jiná než Výše uvedená uid a gid. Dále budete muset nastavit pro Výše uvedený účet nějaké heslo pomocí příkazu passwd.
Pak by mohl skript ppplogin vypadat následovně:
#!/bin/sh
# ppplogin - skript pro spuštění pppd při přihlášení
mesg n
stty -echo
exec pppd -detach silent modem crtscts
Příkaz msg zabrání tomu, aby mohli ostatní uživatelé zapisovat do tty, například pomocí příkazu write. Příkaz stty vypíná opakování znaků. To je nutné z toho důvodu, že jinak by se na protějším počítači opakovaly všechny znaky, které pošle. Nejdůležitější z Výše uvedených voleb démona pppd je volba -detach, protože zabraňuje démonu pppd odpojení od tty. Pokud tuto volbu neuvedeme, přejde démon pppd do pozadí a tím pádem se ukončí i skript příkazového interpretu.. To by ve svém důsledku mohlo znamenat zavěšení sériové linky a ukončení spojení. Volba silent sděluje démonu pppd, aby před začátkem posílání paketů vyčkal na příchozí paket z volaného systému. Tato volba zamezí vypršení přenosové doby v případě, kdy je volající systém příliš pomalý při spouštění svého klienta PPP. Volba modem sděluje démonu pppd, aby kontroloval linku DTR, pomocí níž lze zjistit, zda protějšek neukončil spojení. Volba crtscts zapíná hardwarové řízení toku dat.
Kromě těchto voleb můžete vyžadovat určitý druh ověření totožnosti, například pomocí volby auth v příkazové řádce nebo v globálním souboru s volbami. Manuálové stránky se také zmiňují o speciálních volbách, které slouží k zapnutí nebo vypnutí protokolů na ověření totožnosti.