Łącza dzierżawione
Poniżej opisujemy poprawną konfigurację serwerów działających pod kontrolą systemu Linux, używanych przez naszych klientów.

Łącza dzierżawione o prędkościach od 33.6 do 460.8 kbps są zestawiane za pomocą protokołu PPP. Od strony CETI łącze jest obsługiwane przez nowoczesny, wyspecjalizowany ruter działający pod kontrolą Linuxa 2.2. Postawienie Linuxa po stronie klienta pozwala na optymalne wykorzystanie łącza, często jest on również wykorzystywany jako firmowy serwer poczty i innych usług w sieci lokalnej. Przedstawione niżej informacje dotyczą także w większości FreeBSD i innych systemów kompatybilnych z Unixem.

Pod Linuxem połączenie PPP jest obsługiwane przez sterownik w jądrze systemu oraz program pppd. W trakcie kompilacji jądra należy włączyć opcję "PPP (point-to-point) support" w sekcji "Network device support". Nawiązujący połączenie program pppd może być uruchamiany przez crond lub przez init. Zalecamy to drugie rozwiązanie, jako efektywniejsze. W tym celu do pliku /etc/inittab należy dopisać następującą linijkę:

	D1:345:respawn:/usr/sbin/pppd /dev/ttyS0

Po zakończeniu konfiguracji należy wydać polecenie init q w celu przeładowania tablicy inittab.

Jeśli modem jest podłączony do portu innego niż ttyS0 (COM1), to należy to uwzględnić, ustawiając inny port ttyS. Program pppd korzysta także z pliku /etc/ppp/options, w którym należy określić dodatkowo następujące opcje:

	lock
	crtscts
	modem
	asyncmap 0
	lcp-echo-failure 10 
	lcp-echo-interval 30

Łącza 33.6 Kbps
Łącza 33.6 kbps są obsługiwane z reguły przez zwykłe modemy, wymagające inicjalizacji za pomocą komend AT. W tym celu, do pliku /etc/ppp/options należy dopisać opcję:

	connect '/usr/sbin/chat -t 55 -f /etc/ppp/chat'

W pliku /etc/ppp/chat powinny znajdować się wszystkie komendy AT powodujące inicjalizację modemu oraz nawiązanie połączenia. Uniwersalna zawartość pliku chat to:

	ABORT "NO CARRIER"
	""
	ATZ
	OK
	ATD
	CONNECT

Dodatkowo, do pliku /etc/ppp/options należy dopisać opcję 115200, określającą prędkość pomiędzy modemem a komputerem. Wykorzystanie maksymalnej prędkości portu szeregowego pozwala na poprawną pracę kompresji sprzętowej modemu. Łącza 57,6 i 115,2 kbps
Łącza o prędkościach 57,6 oraz 115,2 kbps są obsługiwane z reguły przez modemy Goramo, Multilink, które nawiązują połączenie automatycznie i nie wymagają żadnej inicjalizacji programowej. W przypadku takich łącza do pliku /etc/ppp/options należy dopisać liczbę określającą prędkość łącza (57600, 115200), ponieważ powinna ona być identyczna jak prędkość między komputerem a modemem.
Kompresja sprzętowa oraz programowa
Standardowe modemy 33,6 kbps posiadają z reguły kompresję sprzętową MNP5 oraz V.42bis, która domyślnie jest włączona. Funkcji takiej nie posiadają wyżej wymienione modemy na łącza 57600 oraz 115200. W ich przypadku można wykorzystać kompresję programową, działającą w warstwie protokołu PPP. W przypadku Linuxa dostępne są dwa algorytmy: BSD oraz Deflate, oba udostępniane przez ruter CETI.

Kompresja BSD jest obsługiwana przez praktycznie wszystkie używane obecnie wersje jąder Linuxa oraz programu pppd. Jest ona jednak dość mało odporna na błędy transmisji i zapewnia gorszy współczynnik kompresji niż Deflate. Ten ostatni algorytm jest dostępny w nowszych wersjach jądra Linuxa oraz programu pppd. Obecność obu algorytmów można stwierdzić, sprawdzając czy w katalogu /lib/modules/wersja_jądra/net znajdują się pliki bsd_comp.o oraz ppp_deflate.o.

Aby pppd podczas nawiązywania połączenia negocjowało użycie wybranego algorytmu kompresji należy dodać jedną z poniższych opcji do pliku /etc/ppp/options:

	deflate 12,12
	bsdcomp 12,12

Należy się także upewnić, że plik /etc/conf.modules zawiera poniższe opcje:

	alias ppp-compress-21 bsd_comp
	alias ppp-compress-24 ppp_deflate
	alias ppp-compress-26 ppp_deflate

W niektórych przypadkach nawet dla zwykłych modemów poprawienie przepustowości łącza można osiągnąć przez wyłączenie kompresji sprzętowej i włączenie kompresji Deflate. Kompresję sprzętową wyłącza się za pomocą odpowiednich komend AT, zależnych od modelu (AT&K0 dla modemów USR/3COM, AT%C0 dla modemów na układach Rockwella, AT&K3 dla modemów Zyxel). Współdzielenie łącza
Szczególnie w przypadku łącz 33,6 kbps często występuje problem znacznego obciążenia łącza przez kilku korzystających z niego użytkowników. Często zdarza się, że jedna aplikacja (np. FTP) zajmuje całe pasmo, wprowadzając znaczne opóźnienia w przesyłaniu innych danych. Efekt ten dotyczy głównie danych ściąganych przez użytkowników z sieci i można go ograniczyć wyłącznie po stronie rutera CETI, który w przypadku szybkich transferów ,,wpycha'' dane w łącze z prędkością przekraczającą jego fizyczną przepustowość. W celu jego ograniczenia na każdym łączu od strony CETI działa specjalny algorytm SFQ (Stochastic Fairness Queueing), który przeciwdziała przejmowaniu łącza przez jedną aplikację, starając się podzielić ,,sprawiedliwie'' pasmo między kilka niezależnych strumieni danych. Jeśli zdarza się, że problem ten występuje także w przypadku danych wysyłanych z sieci lokalnej na zewnątrz, można mu zaradzić na kilka sposobów:

1. Zmniejszając MTU (Maximum Transfer Unit) łącza. W tym celu do pliku /etc/ppp/options należy dopisać opcję mtu 576 i zresetować połączenie. Ma to sens wyłącznie w przypadku łącz o prędkości 33,6 kbps, na szybszych łączach zmniejszenie MTU pogorszy jego wykorzystanie.

2. Zmniejszając wielkość kolejki interefejsu PPP. Można to zrobić przy pomocy polecenia ifconfig:

   	ifconfig ppp0 txqueuelen 3
   

3. Włączając na interfejsie algorytm SFQ. Wymaga to jednak posiadania jądra Linuxa w odpowiedniej wersji oraz konfiguracji. W przypadku chęci uruchomienia SFQ na łączu prosimy o kontakt z działem technicznym pod adresem tech@ceti.pl.

Maskowanie IP
Maskowanie adresów IP (ang. masquerading) jest techniką, pozwalającą na korzystanie z Internetu komputerom, nie posiadającym adresów IP z publicznej puli. W takim wypadku wymagany jest tylko jeden publiczny adres IP dla rutera linuxowego, który łączy sieć lokalną z CETI. Komputerom w sieci lokalnej przydziela się adresy należące do jednej ze specjalnych pul prywatnych, zdefiniowanych przez RFC 1918. Maskowanie adresów IP realizuje Linux. Wszystkie komputery łączące się z maskowanych adresów są na zewnątrz widziane z jednym i tym samym adresem rutera linuxowego.

Zalety maskowania IP są oczywiste: oszczędność publicznych adresów IP, łatwiejszy przydział i administracja prywatnymi adresami IP (nie trzeba się martwić, czy przypadkiem nie braknie) oraz bezpieczeństwo (komputerów znajdujących się za maskaradą nie można dosięgnąć z zewnątrz). Wady wynikają przede wszystkim z ostatniej cechy - na komputerach znajdujących się w sieci maskowanej nie można uruchomić żadnego serwera dostępnego ze świata. Wynika stąd wniosek, że maskowanie adresów IP najlepiej nadaje się dla sieci, w których znajdują się głównie komputery pełniące rolę stacji roboczych, które nigdy nie będą pełnić roli serwera.

Uruchomienie maskowania adresów IP składa się z następujących etapów:

1. Wybranie puli adresów prywatnych, z których przydzielane będą adresy dla maskowanych komputerów. Zalecamy korzystanie z sieci 192.168.0.0/24 (do wykorzystania ponad 65 tys. adresów IP) lub 10.0.0.0/8 (ponad 16 mln.).

2. Przydzielenie komputerom adresów z wybranej puli, zgodnie z lokalnymi potrzebami.

3. Zapewnienie obsługi maskowania IP przez jądro Linuxa działającego na ruterze po stronie klienta. Wymaga to włączenia następujących opcji w sekcji Networking options:
   • Network firewalls
   • IP: firewalling
   • IP: masquerading

   Należy również włączyć dodatkowe opcje dotyczące modułów maskujących określone protokoły (FTP, IRC), zależne od wersji jądra. Warto pamiętać, że moduł maskujący protokół ICQ nie jest dołączony do jądra i należy go ściągnąć osobno.

4. Ostateczna konfiguracja maskowania adresów IP przy pomocy programów ipfwadm lub ipchains, w zależności od wersji systemu. Szczegółowe informacje można znaleźć na przykład w IP Masquerading Mini HOWTO.

---

Domena odwrotna
Naszym klientom umożliwiamy delegację domeny odwrotnej dla przydzielonych na łącza dzierżawione pul adresowych o dowolnej wielkości. Metoda delegacji domeny IN-ADDR.ARPA dla podsieci mniejszych od klasy C jest szczegółowo jest ona opisana w dokumencie RFC 2317. Poniżej opisaliśmy tę procedurę stosowaną przez nas w praktyce.

Zalecany serwer DNS to BIND przynajmniej w wersji 8.x. Starsze wersje miewały problemy z poprawnym rozwiązywaniem nazw odwrotnych z domen delgowanych w ten sposób.

W tym przykładzie przyjmiemy, że przydzielona Państwu pula to na przykład szesnaście adresów z podsieci 192.168.1.128/28. Wobec tego, domena odwrotna dla klasy C zawierającej tę podsieć będzie miała postać 1.168.192.IN-ADDR.ARPA.. Proszę zwrócić uwagę na to, że wykorzystane są w niej tylko 3 pierwsze liczby adresu oraz że ich kolejność jest odwrócona (szczegóły można znaleźć w RFC 1035, rozdział 3.5).

Delegacja domeny odwrotnej dla 16 adresów przydzielonej Państwu sieci wymaga kolejno:

1. Przygotowania dwóch serwerów DNS (nadrzędnego i zapasowego). Zazwyczaj serwerem nadrzędnym będzie serwer stojący po Państwa stronie. Serwer zapasowy zapewnia firma CETI.

2. Określenia nazwy delegowanej części domeny odwrotnej. Nazwa ta może być w praktyce dowolna - w praktyce wybierać należy nazwy krótkie (maks. 8 znaków), składające się wyłącznie z małych liter i jednoznacznie określające właściciela delegacji (np. nazwa firmy). Przyjmijmy, że w tym przykładzie wybraliśmy nazwę firma.

3. Skonfigurowania nadrzędnego serwera DNS, tak by obsługiwał on domenę nazwa.ccc.bbb.aaa.IN-ADDR.ARPA.. W naszym przykładzie byłaby to więc domena firma.1.168.182.IN-ADDR.ARPA.. W pliku zawierającym dane tej domeny należy umieścić rekordy PTR określające nazwy hostów o określonych adresach IP, tak jak w zwykłej konfiguracji domeny odwrotnej.

4. Wysłania następujących danych na adres dns@ceti.pl:
   • pełnej nazwy domeny odwrotnej (nazwa.ccc.bbb.aaa.IN-ADDR.ARPA.)
   • adresu nadrzędnego serwera DNS obsługującego tę domenę