IP, ICMP, UDP, TCP :: Adresacja i routing :: Quality of Service :: Adresy IPv4 :: Typy transmisji danych - unicast, broadcast i multicast :: Routing :: Multicast w IPv4 :: IPv6 - adresy, zmiany, ... :: Tunele, VPN, szyfrowanie, ... :: Konfiguracja sieci :: Polecenia do konfiguracji sieci :: Pliki z konfiguracją sieci :: Linki

Podstawy sieci IP

Sieć jest to zasadniczo zbiór hostów (urządzeń wykorzystujących sieć do komunikacji, takich jak komputery, drukarki sieciowe, ...) oraz infrastruktury sieciowej (urządzenia aktywne, okablowanie). W przypadku bardziej abstrakcyjnego patrzenia na zagadnienia sieciowe (właśnie od strony protokołów wyższych warstw niż sprzętowa - takich jak IP) na sieć można patrzeć tylko jako na zbiór hostów (posiadających identyfikujące je numery). Dla funkcjonowania sieci konieczne jest zapewnienie dobrze określonych zasad jej działania - właśnie zbiorami takich zasad wymiany informacji są protokoły sieciowe.

W dokumencie tym zajmować się będziemy zbiorem protokołów określanych mianem TCP/IP. Protokoły te operują na pakietach (zasadniczo o pakietach mówimy przy IP i TCP natomiast przy UDP mówimy o datagramach) czyli porcji przesyłanej informacji do której dodane zostały dodatkowe informacje - nagłówek zawierający m.in. adresy odbiorcy i nadawcy. Protokoły te działają w warstwach 3 (sieciowa) i 4 (transportowa) modelu OSI czyli pomiędzy warstwami sprzętowymi (w których funkcjonuje np. Ethernet) a warstwami aplikacji (w których działa np. HTTP, SMTP, XMPP, ...). Właśnie utworzenie zunifikowanych zasad komunikacji w tych warstwach (zwłaszcza w warstwie sieciowej gdzie działa IP) umożliwia istnienie internetu (między sieci), czyli logicznej struktury łączącej różne sprzętowo sieci w jedną sieć logiczną w której mogą swobodnie działać protokoły wyższej warstwy (internet w tym znaczeniu jest innym terminem niż "Internet" (pisany wielką literą), czyli globalna sieć komputerowa).

IP, ICMP, UDP, TCP

Protokół IP (Internet Protocol) odpowiedzialny jest przede wszystkim za sposób adresacji hostów oraz reguły komutacji pakietów (routing). Jest on niejako wspomagany przez kolejny protokół z tej rodziny - ICMP (Internet Control Message Protocol), którego zadaniem jest przekazywanie informacji kontrolnych np. o nieosiągalności hosta docelowego, odrzuceniu przetwarzania pakietu ze względu na zbyt dużą liczbę skoków (gdy wartość pola TTL z nagłówka IP wyniesie zero) a także pingi (zarówno żądanie jak i odpowiedź).

Niejako w oparciu o protokół IP działają protokoły warstwy transportowej takie jak UDP, TCP, czy też (mniej znane protokoły czasu rzeczywistego, transmisji strumieniowych): RTP, RTCP i SCTP. Najprostszym protokołem warstwy transmisji wydaje się być UDP, protokół ten umożliwia przesłanie informacji pomiędzy dwoma hostami IP i nie kontroluje on tego czy została ona przesłana poprawnie. Z kolei TCP czuwa nad tym by przesłana informacja dotarła do adresata i była nieuszkodzona, natomiast w przypadku problemów informacja wysyłana jest ponownie. TCP w związku z tym w przeciwieństwie do UDP musi otworzyć połączenie i wykorzystywać je do kontroli poprawności przesłania informacji, wymaga zatem przesłania większej liczby pakietów (co może prowadzić do pewnych opóźnień itp). W związku z tym TCP używany jest tam gdzie konieczna jest kontrola poprawności transmisji (oraz ponowne wysłanie zgubionego pakietu), UDP tam gdzie nie jest to potrzebne (a liczy się czas). Dodatkowo zarówno UDP jak i TCP na każdym z hostów wyróżniają numeryczny identyfikator dla aplikacji/procesu/usługi będącego odbiorcą czy też nadawcą informacji zwany numerem portu (popularne usługi typu WWW, SMTP posiadają określone domyślne porty dla swoich protokołów).

RTP jest dość specyficznym protokołem - często zaliczany jest do warstwy transportowej gdyż działa poniżej typowych protokołów warstwy aplikacji, jednak dane które opisują nie są informacjami systemowymi/sieciowymi a właśnie aplikacyjnymi, ponadto działa on powyżej protokołów transportowych (zazwyczaj nad UDP). Może przenosić w jednej sesji kilka strumieni, ale zazwyczaj dla każdego strumienia tworzona jest osobna sesja (zestaw portów). Protokół ten umożliwia identyfikację zawartości pakietu, identyfikację kolejności pakietów w strumieniu. Pozwala także na przepuszczanie ruchu przez mostki maskujące oryginalne adresy, zmieniające medium, replikujące strumień (replikowany unicast, który wydaje się być bardzo dobrym rozwiązaniem gdy z jakiś powodów multicast nie może zadziałać), czy też nawet łączące strumienie z kilku źródeł. Współpracujący z nim RTCP służy do przesyłania raportów z informacjami o stratach, opóźnieniach itp oraz wzajemnej synchronizacji mediów pomiędzy strumieniami - np. synchronizacji audio z wideo).

Adresacja i routing

Quality of Service

QoS są to techniki gwarantujące jakość usługi. Najczęściej stosowaną techniką zaliczaną do QoS jest dynamiczny podział przepustowości łącza z wykorzystaniem algorytmów takich jak HTB, CBQ. Nie jest to jednak prawdziwy QoS, gdyż mechanizmy te to coś więcej niż tylko prosty podział pasma. O QoS'ie możemy zaczynać mówić gdy system kolejkowania uwzględnia priorytety dla pewnych typów ruchu (m.in. na podstawie pola ToS). Kolejki priorytetowe mogą być realizowane jako wagowe - cyklicznie z każdej klasy wysyłamy proporcjonalnie do wagi, lub bez-wagowy (klasa ważniejsza może zagłodzić klasy o mniejszym priorytecie, gdyż brany jest z ważniejszej dopóki są lub nie pojawią się jeszcze ważniejsze).

Istnieją dwie podstawowe architektury systemów QoS:

  • IntServ - Odbiorca w oparciu o informacje uzyskane od nadawcy na temat parametrów transmisji dokonuje rezerwacji zasobów w wszystkich routerach na ścieżce łączącej go z nadawcą (wykorzystuje do tego protokół RSVP), każdy z routerów decyduje czy może spełnić te wymagania (gdy jedne nie może cała operacja nie udaje się). Wyróżnia się klasy ruchu:
    • Best Effort - standardowa
    • Guaranteed Service - gwarancja dostępności pasma i opóźnienia
    • Control Load Service - zapewniamy mało obciążony kanał, ale bez gwarancji
    Jak wspomniałem każdy strumień negocjowany jest indywidualnie, poprzez mechanizm Addmision Control (podawane są specyfikacje filtru - jak identyfikować ten ruch, specyfikacje przepływu, itd). Ponadto informacje o rezerwacji muszą być okresowo odnawiane co skutkuje znacznym ruchem sygnalizacyjnym.
  • DiffServ - Nie ma ścisłych gwarancji dla jakiegokolwiek strumienia. Na brzegu użytkownik negocjuje SLA i ruch jest kontrolowany pod względem tego SLA (m.in. ustawianie i kontrola pola ToS). Może występować także zarządca pasma (en:Bandwidth Broker), z którym klienci komunikują się przy pomocy protokołu RSVP i negocjują z nim kontrakty SLA, natomiast sam BB dokonuje rezerwacji zasobów w routerach i kontroluje ich stan (zazwyczaj z wykorzystaniem protokołu COPS).

Ciekawszym protokołem (ze względu na dawanie gwarancji i globalność - działanie na całej ścieżce) wydaje się IntServ. Niestety ze względu na gorszą skalowalność oraz konieczność zgodności z tym protokołem wszystkich routerów na wybranej ścieżce jest on rzadko spotykany.

Adresy IPv4

Adresy hostów w sieciach TCP/IP nazywane są adresami IP, w wersji 4 protokołu IP jest to 32 bitowa liczba, zapisywana najczęściej w notacji kropkowo dziesiętnej (gdzie każdy bajt (ciąg 8 bitów) zapisywany jest jako liczba dziesiętna rozdzielana kropką od pozostałych). Początkowa (określona przez maskę podsieci) liczba bitów stanowi adres sieci, reszta jest adresem hosta w danej (pod)sieci.

Wspomniana maska podsieci jest również 32 bitową liczbą, w której pierwsze N bitów ma wartość jeden a kolejne 0. W wyniku operacji binarnego AND między maską a adresem IP hosta otrzymujemy adres sieci, pozwala ona zatem na ustalenie czy dany adres IP należy do tej samej podsieci co adres IP hosta. Maskę możemy zapisywać w notacji kropkowo-dziesiętnej bądź w formie skróconej gdzie po ukośniku podajemy liczbę jedynek w masce (N).

Maska podsieci informuje także o liczbie numerów IP wchodzących w skład danej sieci (wynosi ona dla IPv6 232-N). Dwa spośród numerów IP należących do każdej podsieci mają specjalne znaczenie: pierwszy - jest adresem sieci (identyfikuje sieć), ostatni jest adresem rozgłoszeniowym sieci (wysłane na niego informacje trafią do wszystkich hostów w tej sieci). Zachęcam też do zapoznania się z programem demonstrującym zasady adresacji IP: numeracja_ip.c.

Wyróżnia się także specjalne adresy (sieci) IP: 0.0.0.0/0 - cały Internet, 127.0.0.0/8 (głownie adres 127.0.0.1) - pętla zwrotna (czyli komunikacja hosta lokalnego ze sobą), 224.0.0.0/4 - multicast oraz adresy sieci prywatnych: 10.0.0.0 do 10.255.255.255, 172.16.0.0 do 172.31.255.255 i 192.168.0.0 do 192.168.255.255. Warto wspomnieć o tym że kiedyś stosowany był także podział na klasy sieci A, B i C odpowiadające maskom /8, /16 i /24 oraz klasy D, E i F (adresy 224.0.0.0 do 254.0.0.0).

Więcej na temat szóstej wersji IP (IPv6, wprowadzającej m.in. 128 bitowe adresy) tutaj.

Typy transmisji danych - unicast, broadcast i multicast

Z sieciami opartymi na komutacji pakietów (takimi jak IP) najczęściej kojarzona jest transmisja pomiędzy dokładnie dwoma hostami, gdzie każdy pakiet ma jednoznacznie określonego nadawcę, transmisję taką określa się mianem unicast. Oprócz niej możliwe są także transmisje typu broadcast (pakiet wysyłany jest na adres rozgłoszeniowy sieci - wynik operacji binarnego OR między adresem sieci i binarnie zanegowaną maską sieci) - adresatem jest wtedy każdy host w sieci lokalnej oraz transmisje multicast - transmisja do wybranej grupy hostów (tutaj wykorzystywane są adresy należące do sieci 224.0.0.0/4 i identyfikują one "kanał nadawczy" a nie unikalny host. Więcej na temat multicastu tutaj. Ponadto możliwe są transmisje anycast (jest to w zasadzie unicast z inną formą adresacji) - komunikacja w tym wypadku zachodzi pomiędzy dwoma hostami, przy czym host zdalny nie posiada unikalnego w skali globalnej adresu (adres oznacza jakąś grupę hostów lub pojedyncze oddalone hosty rozróżniane na zasadach routingu).

Routing

Internet składa się z szeregu podsieci (wyznaczanych właśnie przez maski), na granicach (w miejscach połączeń) tych sieci pracują routery (urządzenia odpowiedzialne za kierowanie pakietów do odpowiednich sieci). Router jest hostem podłączonym do kilku sieci fizycznych (będących także osobnymi sieciami IP) i skonfigurowany do przekazywania pakietów między nimi. Router na podstawie adresu odbiorcy oraz tablicy routingu (zawierających informacje o tym jakie sieci znajdują się na jakich złączach oraz jakie są kolejne routery do których należy przesyłać pakiet) decyduje jaką trasą ma zostać przesłany dany pakiet. W szczególności najbliższy danemu hostowi router obsługujący przesył pakietów do danej sieci nazywany jest bramką (gateway), w przypadku zwykłych hostów na ogól jest jedna bramka obsługująca siec 0.0.0.0/0 (do której kierowane są wszystkie pakiety nie adresowane do sieci lokalnej). Router wykorzystywany jest również na styku sieci korzystających z prywatnych (nie routowanych) zakresów IP i sieci publicznej, wówczas pełni on także funkcję translacji adresów IP.

Mechanizm Translacji Adresów Sieciowych (NAT) pozwala na udostępnienie jednego połączenia do sieci publicznej (współdzielenie jednego publicznego IP) przez hosty w sieci lokalnej posiadające wyłącznie IP wewnętrzne. Jest to najogólniejsza metoda modyfikacji adresów sieciowych (IP-Masquerade oraz PAT - Port Address Translation są jej szczególnymi przypadkami) pozwala ona na dynamiczne zastępowanie adresów wewnętrznych adresem publicznym, jak również mapowanie kombinacji "IP:port" publicznych na takie kombinacje w sieci wewnętrznej. Pozwala nie tylko na udostępnianie Internetu w sieciach wewnętrznych mających jedno publiczne IP, ale również na rozkładanie obciążenia (np. ruchu do serwera WWW) na kilka hostów w sieci wewnętrznej. Praktyczne realizacje NAT są również najprostszą formą zapory sieciowej zwanej od angielskiego "firewall" ścianą ogniową.

Oczywiście routing nie sprowadza się tylko do statycznie zapisanych reguł na którym z interfejsów jest dojście do danej sieci. Powszechnie wykorzystuje się protokoły routingu dynamicznego (np. BGP). Umożliwiają one automatyczną wymianę informacji o najlepszych trasach pomiędzy routerami, równoważenie obciążenia łącz (pakiet może pójść trasą ogólniej gorszą ale obecnie mniej zajętą), a także redundancję łącz - ta sama pula IP może być rozgłaszana przez kilku różnych dostawców łącz, co powoduje że awaria jednego z nich nie powoduje zaniku dostępności danych hostów.

Więcej szczegółów o podziale łącza i skryptach NAT w skrypcie routera linuksowego. Zobacz w Sieci: Routing dynamiczny @ Wikibooks, Protokół BGP: podstawy działania, budowa styku z internetem, projekt bgp blackholing pl, Telefon IP - Protokoły sieciowe - IP wersja 4, Typy NATów, Sieci nie tak znowu lokalne

Multicast w IPv4

Standardowo mamy dwa typy transmisji: unicast (pakiet zawiera unikalny adres odbiorcy i przeznaczony jest tylko dla niego) oraz broadcast (pakiet wysyłany jest na adres rozgłoszeniowy podsieci i przeznaczony jest dla wszystkich komputerów w tej sieci, pakiety te nie są routowane - nie opuszczają sieci lokalnej, zatem 255.255.255.255, który jakby mogło się wydawać powinien oznaczać każdy komputer w Internecie, oznacza tylko każdy komputer w sieci lokalnej). Jeżeli chcemy myśleć o rozsądnej transmisji klasycznej telewizji przez internet, konieczne wydaje się znalezienie metody transmisji jeden do wielu, niewymagającej powielania identycznych pakietów (różniących się tylko adresem odbiorcy). Taką metoda transmisji jest właśnie multicast.

Multicast korzysta z zarezerwowanej do tego celu klasy adresów "D" - adresy 224.0.0.0 do 239.255.255.255 (adresy 224.0.0.0 do 224.0.0.255 zarezerwowane są na wewnętrzne funkcje protokołu), zakres 224.1.0.0-238.255.255.255 przeznaczony jest na alokowane dynamicznie adresy globalne (wykorzystane do tego mogą być protokoły SDR lub MASC, jednak w chwili obecnej nie został ustalony mechanizm ich alokowania, praktykuje się alokacje sieci /24 dla posiadaczy numerów AS na zasadzie 233.AS.AS.0/24), natomiast 239.0.0.0/8 przeznaczone jest na adresy prywatne wykorzystywane w obrębie swojej "domeny". Komputery nieobsługujące multicastu powinny ignorować te pakiety, natomiast routery nie multicastowe nie przekazywać ich; i zasadniczo tak sie dzieje ... . Adresy te mają inne znaczenie niż w przypadku unicastu - nie identyfikują one żadnego konkretnego hosta, wyznaczają natomiast swego rodzaju grupę hostów a właściwie (jako że może to być grupa zmienna w czasie) swego rodzaju odpowiednik kanału telewizyjnego na którym coś jest nadawane (i kto chce ten słucha). Również pole TTL ma tutaj swego rodzaju specjalne znaczenie (z wykorzystaniem tego pola tworzy się regiony - pewne routery brzegowe nie przekazują pakietów o zbyt niskim TTL - pomimo iż jest różny od zera (!), np. poza Warszawę i okolice nie powinien wyjść pakiet o TTL < 32, a poza Europę o TTL < 128).

Router obsługujący Multicast gromadzi informacje od hostów (w tym innych routerów) do których przekazuje ruch o tym jakimi multicastowymi numerami IP są zainteresowane wykorzystując protokół IGMP i przekazują tylko te pakiety. W przypadku najpopularniejszej wersji drugiej tego protokołu router odpytuje co pewien czas czy są jacyś "klienci" zainteresowani odbiorem transmisji multicasowych (pytania wysyłane są na multicastowy adres rozgłoszeniowy - 224.0.0.1 lub gdy są reakcją na zgłoszenie chęci opuszczenia grupy na adres danej grupy). Na pytanie ("Query") odpowiada jeden host (który pierwszy ten lepszy) wysyłając "Report", hosty same z siebie oprócz wspomnianej informacji o opuszczaniu grupy mogą wysłać także "query" gdy chcą rozpocząć odbiór transmisji multicastowej. W wersji trzeciej hosty oprócz adresu grupy mogą poinformować także o źródłach (adresach źródłowych hostów nadających do tej grupy), router również może poinformować o dostępnych źródłach. Pakiety "report" wysyłane są tylko do routerów, ponadto każdy host należący do grupy odpowiada na pakiet "Query". W sieciach opartych na ethernecie do przesyłu pakietów multicastowych wykorzystywane są multicastowe adresy MAC - ich zakres to połowa jednego OUI, a zaczynają się od 0x01005e. Jako że jest ich mniej niż multicatowych adresów IP są one dynamicznie przydzielane grupom multicastowym. Możliwe jest także rozbijanie transmisji multicast na unicastowe przez jakiś serwer w sieci lokalnej (np. dla hostów klienckich nie obsługujących multicastu, bądź w przypadku problemów z NAT).

Wspomniany IGMP działa tylko pomiędzy routerem a hostami. Do wymiany informacji pomiędzy routerami wykorzystuje się inne protokoły routingowe - DVMRP, MOSPF, PIM-DM, PIM-SM, ... . Routing multicastowy oparty jest zarówno o adres źródła jak i grupy multicastowej, z wymienionych protokołów tylko PIM-SM obsługuje współdzielone drzewa multicastowe, w których routing nie uwzględnia źródła. Ponadto router przekazuje informację tylko gdy pochodzi z interfejsu odpowiedniego dla źródła. DVMRP funkcjonuje w oparciu o tworzenie drzew bazujących na adresie sieci źródłowej i grupy multicastowej w sposób całkowicie niezależny od routingu unicastowego, drzewa te są okresowo zalewane ruchem, po czym routery przesyłają informację jakich danych nie chcą (nie mogą poinformować że chcą zacząć odbierać jakąś transmisję). MOSPF jest multicastowycm rozszerzeniem OSPF, wykorzystuje informacje tamtego protokołu i dodatkowe zapytania o odbiorców multicastowych do tworzenia drzewa w momencie rozpoczęcia nadawania przez jakieś źródło, w przypadku wielu stref zakłada router brzegowy subskrybuje wszystkie grupy jeżeli ma jakichkolwiek odbiorców. Wspomniany już PIM-SM funkcjonuje w oparciu Rendezvous Point (RP), do których wysyłane są treści od nadawców (początkowo tunelem unicastowym, a dopiero po odebraniu takich danych RP inicjalizuje ścieżkę multicast do danego źródła). Również do RP kierowane są pakiety "Join" z informacją o chęci zasubskrybowania grupy multicastowej, nie zawierają jednak one informacji o źródle, a ich ścieżka tworzy drzewo multicastowe. Po zestawieniu połączenia poprzez RP następuje przełączenie na najkrótszą ścieżkę (wtedy już cała trasa routingu zawiera informacje o grupie i źródle. Niestety multicast nie działa w obecnym Internecie w skali globalnej gdyż bardzo wiele routerów go nie obsługuje. Nadzieją wydaje się być IPv6 gdzie (w odrobinie odmiennej formie multicast jest od początki wpisany w standard).

Na koniec wspomnę jeszcze o protokołach wyższej warstwy, podstawowym jest odpowiednik UDP (ten zresztą też umożliwia korzystanie z multicastu) - RTP (Real-time Transport Protocol), odpowiednikiem TCP (tutaj nie jest możliwy multicast) jest z kolei Multicast Transport Protocol. RTP służący do przekazywania transmisji gdzie nie jest konieczne potwierdzanie (poprawnego) odbioru - np. transmisji radiowych czy telewizyjnych), zapewnia on natomiast odpowiednia kolejność pakietów. MTP zapewnia dotarcie nienaruszonego pakietu.

Więcej o Multicast: Internet Protocol (IP) Multicast, Dźwięk i obraz w Internecie (1): Multicasting, RFC 1112

IPv6 - adresy, zmiany, ...

Główną zmianą wprowadzaną przez nową wersję protokołu IP jest wydłużenie adresów do 128 bitów. Zmianie uległ format nagłówka pakietu oraz dodano kilka innych rozszerzeń (np. kompresję i uwierzytelnianie). Tutaj również pewna pula IP została zarezerwowana dla potrzeb transmisji multicast, jednak została ona podzielona na 14 pul odpowiadających różnym zasięgom transmisji. Adresy zapisywane są zazwyczaj w notacji dwukropokowej, polegającej na zapisywaniu 16bitowych części adresu liczbami szesnastkowymi oddzielanymi dwukropkiem, dodatkowo jeden ciąg zer (o długości będącej wielokrotnością 16 bitów) może być skompresowany (pominięty) co daje w zapisie dwa dwukropki ::.

Kolejną dość istotną cechą IPv6 jest autokonfiguracja. Polega ona na tym że dla podsieci będących LAN'em przydzielana jest pula z maską /64 co umożliwia tworzenie unikalnych numerów IP w oparciu o (niepowtarzalne) numery sprzętowe MAC; adres taki (dla adresu MAC 11:22:33:44:55:66) będzie miał postać: 64bitowy_prefiks_sieci:1322:33FF:FE44:5566 (pierwsza część adresu MAC zwiększana jest o 2, w środku wstawiane jest FFFE). 64 bitowy prefiks sieci jest informacją rozgłaszaną przy pomocy ICMPv6 przez routery (mechanizm radvd); natomiast jeżeli host nie uzyskał wspomnianego prefiksu w jego miejsce wstawiane jest fe80:: (czyli fe80:0000:0000:0000) - taki adres nazywa się "link-local" (nie jest on routowany do sieci zewnętrznych, jednak zawsze (także gdy prefiks został uzyskany) może być używany wewnątrz sieci lokalnej). Radvd rozgłasza także informacje routingowe (takie jak adres bramy - dhcpv6 tego nie potrafi), niestety nie da się rozgłaszać w ten sposób innej od standardowej dla LAN długości prefixu. Oczywiście nadal możemy korzystać z przydziału IP przez DHCP oraz ręcznego przydziału IP. Omawiając wersję 6 IP należy wspomnieć także o zmianach w samej budowie nagłówków IP - przede wszystkim budowa modularna, ale także np. zastąpienie TTL (wyrażanego mniej więcej w sekundach) przez licznik zliczający w dół przekazania pakietu przez routery.

W IPv6 na transmisje multicastowe przeznaczone zostały adresy postaci ffyx::, gdzie x odpowiada za zasięg który obejmuje transmisja multicastowa, y koduje natomiast flagi dotyczące typu adresu (0=adres przydzielony na stałe przez IANA - dobrze znane usługi, 1=nie przydzielone stale, ...). Od strony użytkownika najciekwasze wydają się adresy postaci ff3x::, które budowane są w oparciu o maksymalnie 64 bitowy prefiks sieci adresów unicast - dla sieci o adresie prefix::/MM będzie to adres ff3x:00mm:prefix:gropid, gdzie mm jest zapisaną w systemie szesnastkowym wartością MM (RFC3306). W 6 wersji protokołu nie występują adresy rozgłoszeniowe - zostały one zastąpione specyficzną postacią adresów multicastowych (oznaczających wszystkie węzły - ff0x::1, wszystkie routery - ff0x::2, np. dla x=2 w zakresie Link-Local).

Każdy unicastowy adres IPv6 może pełnić funkcję adresu anycast - pakiety wysyłane na ten adres dostarczane są do najbliższego (wg konfiguracji routingu) hosta, ma to miejsce gdy adres IPv6 jest przypisany do więcej niż jednego interfejsu. W szczególności adresem anycast jest adres sieci postaci prefix::. Adresy tego typu w IPv4 służą m.in. w systemie tuneli 6to4 i jest to adres 192.88.99.1.

Głównym problemem dla końcowego użytkownika korporacyjnego, a także dla części ISP w obecnej formie wdrożenia wydaje się być niemożliwość rozgłaszania prefiksów mniejszych od /32. Sytuacja taka ma miejsce pomimo zrezygnowania z hierarchicznego routingu globalnego (RFC3587 mówi o 45 bitowym global routing prefix poprzedzonym 3 bitowym określeniem polityki adresów) i uniemożliwia multihoming oparty o BGP, a także podzielenie klasy /32 posiadanej przez ISP na dwie sieci o różnych politykach routingu (otrzymanie drugiej /32 przed zapełnieniem 80% posiadanego także jest niemożliwe). Najlepszym rozwiązaniem wydawałoby się zgoda na globalne rozgłaszanie BGP prefixów do /48 włącznie (nasuwa się też chęć rozwiązania problemu brakujących AS w następnej wersji BGP poprzez wykorzystanie prefiksu sieci - tak jak zrobiono to w RFC3306 dla multicastu).

O ile wsparcie dla IPv6 w klasycznych usługach sieciowych jest na bardzo przyzwoitym poziomie (zobacz uwagi konfiguracyjne w usługi sieciowe) to paradoksalnie korzystanie z IPv6 w stosunkowo nowych dziedzinach może być problemem. Na przykład: Korzystanie z IPv6 w Psi wymaga zmiany opcji konfiguracyjnej DNS i rekompilacji programu (zobacz informację na forum Psi), ale nawet pomimo to transfer plików nasłuchuje tylko na adresie IPv4 (0.0.0.0:52610). Problemem w wdrażaniu IPv6 są też routery wifi niedostosowane do obsługi tego protokołu.

Zobacz w Sieci: Omówienie protokołu IPv6, Implementacja serwera i klienta DHCPv6 dla systemów rodziny Linux.

Tunele, VPN, szyfrowanie, ...

Sieci IP umożliwiają tworzenie tuneli, polega to na tym że komputery będące końcami takiego tunelu przyjmują z niego dane, rozpakowują je z IP i na przykład wysyłają dalej (w innym standardzie) bądź przetwarzają w jakiś sposób oraz (analogicznie) pakują dane do przesłania w pakiety IP i wysyłają. Od zwykłego przesyłu danych przez IP odróżnia się to tym iż na ogół końce tuneli są konfigurowane dość sztywno (znaczy się jest z góry określane kto z kim) oraz że dość częstą tą drogą przesyłane są inne protokoły sieciowe (również sam IP).

Do najistotniejszych obecnie zastosowań tuneli należą: tunele IPv6 w IPv4 (umożliwiają korzystanie z IPv6 gdy provider go nie dostarcza bezpośrednio), tunele łączące sieci multicastowe oraz Virtual Private Network (VPN) czyli wirtualne sieci prywatne. VPN polega na utworzeniu między siecią lokalną (na ogół w jakiejś firmie) a odległym hostem tunelu dzięki któremu host ten może zachowywać się tak jakby był bezpośrednio włączony do tej sieci (można by powiedzieć że jest mapowany przez serwer obsługujący VPN na host tej sieci). Oczywiście wymaga to aby na takim hoście znajdowało się odpowiednie oprogramowanie przesyłające cały ruch sieciowy (bądź tylko odpowiednią jego część) do drugiej końcówki tunelu oraz odbierało dane stamtąd. Pewnymi problemami dla VPN mogą być NAT po stronie hosta klienckiego (aby mogło działać wywołanie z sieci lokalnej do tego hosta musi być utrzymywane połączenie - inaczej nie jest on widoczny w sieci publicznej przez którą prowadzony jest tunel).

Kolejną kwestią jest kompresja i szyfrowanie transmisji. Jest to powszechnie stosowane przy VPN, jak również przy innych protokołach; kompresję można wykorzystywać nawet w samym HTTP, szyfrowanie wykorzystywane jest najczęściej w SSH i pochodnych, HTTPS oraz protokołach odbiorczych poczty. Najczęściej spotykane jest szyfrowanie z kluczami asymetrycznymi typu OpenPGP, często w wolnej implementacji GnuPG (GPG). Do najpopularniejszych protokołów należy wspomniany SSH (wraz z pochodnymi takimi jak SCP, SFTP) oraz (wykorzystywany po części przez SSH) działający w warstwie TCP "Secure Sockets Layer" (SSL), na którym opart jest między innymi HTTPS, POP3S, IMAPS, ... . Zarówno SSH jak i SSH posiadają wolne implementacje: www.OpenSSH.org i www.OpenSSL.org

Konfiguracja sieci

Polecenia do konfiguracji sieci

  • arp - manipulowanie tablicą protokołu ARP
  • arping - narzędzie do pingowania z wykorzystaniem zapytań ARP zamiast ICMP
    Debian: iputils-arping
  • arptables - jądrowe reguły filtrowania i routingu pakietów w warstwie drugiej OSI
  • brctl - konfiguracja bridge'ów
    Debian: bridge-utils
  • dhclient - konfiguracja automatyczna interfejsu w oparciu o DHCP
  • dhcpdump - wsparcie dla tcpdump do obsługi DHCP
  • dhcping - narzędzie do testowania DHCP
  • dnstracer - śledzenie trasy zapytań DNS
  • dnswalk - debuger DNS
  • ebtables - jądrowe reguły filtrowania i routingu pakietów dla bridge'ów
  • ethtool - konfiguracja kart ethernetowych pod względem takich parametrów jak prędkość transmisji, duplex, wake on lan, ...
  • ifconfig - konfiguracja interfejsów sieciowych, np. konfiguracja numeru IP i wielkości sieci (maska): ifconfig eth0 up 192.168.24.1 netmask 255.255.0.0 (w FreeBSD ifconfig bge0 up 192.168.24.1 netmask 255.255.0.0 )
  • ifplugstatus - sprawdzanie czy karta ma link (wykryty kabel)
  • ifplugstatus - program informujący o stanie fizycznego połączenia (linku) na karcie ethernetowej
  • ip - konfiguracja sieci IP oraz routingu (umożliwia np. balans obciążenia pomiędzy dwoma łączami - ip route add default scope global nexthop via $IP1 dev $IF1 weight 1 nexthop via $IP2 dev $IF2 weight 1)
  • iperf - pomiar prędkości połączenia sieciowego
  • iptables - jądrowe reguły filtrowania i routingu pakietów
  • iptraf - monitor IP LAN
  • iwconfig - konfiguracja (większości - do części trzeba użyć wlanctl-ng) bezprzewodowych interfejsów sieciowych
  • iwlist - dodatkowe informacje z bezprzewodowych interfejsów sieciowych (przydatna zwłaszcza opcja scan pokazująca dostępne sieci
  • mtr - trasa, straty, opóźnienia itp pakietów do danego hosta
    Debian: mtr mtr-tiny
  • ndisc6 - narzędzie do testowania ICMPv6 Neighbor Discovery
    Debian: ndisc6
  • netcat6 (gnu netcat, netcat) - programiki pozwalające na operowanie wysyłanie pakietów TCP i UDP z definiowaną przez nas zawartością, umożliwia m.in. testowanie usług sieciowych (takich jak smtp, www, jabber, ...), więcej w tutaj
    Homepage: http://netcat.sourceforge.net/ http://www.vulnwatch.org/netcat/
  • netstat - informacje o sieci
  • nload - graficzne (ncurses) pokazywanie wykozystania (prędkości) interfejsów sieciowych
  • nslookup - narzędzia do zamiany adresów dpmenowych na IP i odwrotnie oraz wyciągania innych informacji z DNS (np. rekordy MX)
  • ping - podstawowe narzędzie testowania sieci sprawdza czy można połączyć się z danym hostem (w przypadku problemów z DNS, głównie odwrotnym, przydatna jest opcja -n)
    Debian: iputils-ping
  • rdisc6 - narzędzie do testowania ICMPv6 Router Discovery
    Debian: ndisc6
  • rltraceroute6 - trasa pakietów do danego hosta IPv6 z użyciem UDP/ICMP
    Debian: ndisc6
  • route - konfiguracja routingu, np. ustawienie bramki domyślnej: route add -net 0.0.0.0 netmask 0.0.0.0 gw 192.168.0.1 (w FreeBSD route add -net 0.0.0.0 -netmask 0.0.0.0 192.168.0.1
  • swaks - narzędzie do testowania SMTP
  • tcpdump - monitor sieci, dhcpdump wsparcie dla tcpdump do obsługi DHCP
  • tcpspray6 - narzędzie do pomiaru prędkości łącza z użyciem TCP/IP Discard/Echo
    Debian: ndisc6
  • tcptraceroute6 - trasa pakietów do danego hosta IPv6 z użyciem TCP
    Debian: ndisc6
  • telnet - programy umożliwiają zdalny dostęp do powłoki, a także (podobnie jak netcat) m.in. testowanie usług sieciowych (takich jak smtp, www, jabber, ...)
  • traceroute - trasa pakietów do danego hosta
    Debian: traceroute paris-traceroute tcptraceroute traceroute-nanog traceproto iputils-tracepath
  • ttcp - testuje prędkość połączenia sieciowego (strona domowa, najnowsza wersja oraz mutacja)
  • wireshark - monitor sieci
    Homepage: http://www.wireshark.org/
  • wpa_cli - konfiguracja większości bezprzewodowych interfejsów sieciowych z wsparciem dla WPA
  • wpa_supplicant - konfiguracja większości bezprzewodowych interfejsów sieciowych z wsparciem dla WPA

Pliki z konfiguracją sieci

Za konfigurację sieci odpowiada plik /etc/network/interfaces, po dokonaniu w nim zmian należy przeładować je poleceniem /etc/init.d/networking restart i można sprawdzić przez ifconfig :). Wyjątkiem jest konfiguracja DNS (ta używana "normalnie"), która znajduje się w pliku /etc/resolv.conf (jeżeli z jakiś powodów serwery DNS naszego ISP nam nie odpowiadają możemy użyć ogólnodostępnych serwerów OpenDNS).

Plik /etc/network/interfaces (przykład) zawiera konfigurację dla poszczególnych urządzeń sieciowych, sekcja dla danego urządzenia zaczyna się od iface, po czym następuje nazwa urządzenia (np. eth0), typ adresu (np. inet lub inet6 lub ...) i rodzaju (np. static, dhcp); jeżeli po nazwie jest dwukropek i liczba (np. eth0:0) oznacza to że jest to alias konfiguracji dla danego urządzenia (odpowiada to ifconfig eth0:0 ...). Wpis ten może być poprzedzony linią auto nazw_interfejsu powodującą automatyczne konfigurowanie interfejsu przy starcie systemu (wywołanie /etc/init.d/networking start), przy braku tego wpisu interfejs należy uruchamiać ręcznie przy pomocy ifconfig nazw_interfejsu up.

Po linii określającej konfigurowane urządzenie występują linie określające jego konfigurację. Dla inet czyli IPv4:

  • address - określa adres IP,
  • netmask - maskę podsieci,
  • broadcast - adres rozgłoszeniowy podsieci (może nie być określany),
  • network - adres podsieci (opcjonalne - nie potrzebne dla jąder > 2.0),
  • gateway - określa bramkę (opcjonalne),
  • dns-nameservers - adres serwera DNS (używany tylko rzez resolvconf).

Możemy także korzystać z post-up pre-down itp. w celu wykonania jakiś poleceń po uruchomieniu interfejsu czy przed jego zakończeniem. W ten sposób możemy konfigurować w tym pliku rzeczy normalnie w nim nie ustawiane:

  • konfigurację DNS - post-up echo "nameserver 192.168.0.1" > /etc/resolv.conf
  • dodatkowy adres IP - post-up ip address add broadcast + local 192.168.24.101/24 dev eth0, warto wtedy też użyć pre-down ip address del 192.168.24.101/24 dev eth0
  • wpisy dodatkowych tras routingu - post-up route add ...

Dla inet6 określa się address (w notacji dwukropkowej), netmask (w postaci ilości bitów o wartości 1 w masce) oraz (opcjonalny) gateway. Przydatne może być też hwaddress określające MAC karty sieciowej (zwłaszcza przy niektórych konfiguracjach dhcp).

Z pośród innych ustawień związanych z siecią istotną rolę odgrywa także nazwa hosta lokalnego - ustawiana jest ona w /etc/hostname (może być podana w formie "host.domena", a doraźnie może być zmieniana komendą hostname oraz nazwa systemu pocztowego ustawiana w /etc/mailname. Niektóre z programów wymagają aby nazwa ta wraz z odpowiednim przyporządkowaniem ip znalazła się także w DNSie lub pliku lokalnego rozwijania nazw - /etc/hosts (tu też możemy podawać przypisania nazw innych hostów do ich adresów, gdy z jakiś powodów nie chcemy korzystać do tego celu z DNS).

Zobacz też: man interfaces, man resolv.conf, man ip, konfiguracja wifi.


Copyright (c) 1999-2012, Robert Paciorek (http://www.opcode.eu.org/), BSD/MIT-type license


Redystrybucja wersji źródłowych i wynikowych, po lub bez dokonywania modyfikacji JEST DOZWOLONA, pod warunkiem zachowania niniejszej informacji o prawach autorskich. Autor NIE ponosi JAKIEJKOLWIEK odpowiedzialności za skutki użytkowania tego dokumentu/programu oraz za wykorzystanie zawartych tu informacji.

This text/program is free document/software. Redistribution and use in source and binary forms, with or without modification, ARE PERMITTED provided save this copyright notice. This document/program is distributed WITHOUT any warranty, use at YOUR own risk.

Valid XHTML 1.1 Dokument ten (URL: http://www.opcode.eu.org/abc_of_computing/networks/ip) należy do serwisu OpCode. Autorem tej strony jest Robert Paciorek, wszelkie uwagi proszę kierować na adres e-mail serwisu: webmaster@opcode.eu.org.
Data ostatniej modyfikacji artykulu: '2013-11-17 08:38:02 (UTC)' (data ta może być zafałszowana niemerytorycznymi modyfikacjami artykułu).