Ten wpis również będzie poświęcony tematyce kontroli i kształtowania ruchu sieciowego w linux'ie, z tym, że ograniczymy się tutaj do konfiguracji interfejsów IFB. Działają one na podobnej zasadzie co interfejsy IMQ. Niewątpliwą zaletą interfejsów IFB jest fakt, że są one natywnie wspierane przez kernel linux'a, przez co ich obsługa jest dziecinnie prosta. Wadą jest z kolei to, że nie do końca damy radę kształtować ruch przychodzący do naszej maszyny. Tak czy inaczej, postaramy się skonfigurować te interfejsy i zobaczymy co z nich idzie wycisnąć.

Każdy z nas chciałby, aby jego sieć działała możliwie szybko i bezproblemowo. W przypadku, gdy łącze nie jest zbytnio obciążone, a my jesteśmy jedynym użytkownikiem internetu, to nie doświadczymy raczej żadnych problemów z połączeniem. Rzecz w tym, że im więcej użytkowników ma nasza sieć, tym większe prawdopodobieństwo, że zostanie ona przeciążona, tj. będziemy chcieli przesyłać więcej danych niż sieć jest w stanie obsłużyć. W ten sposób zaczną pojawiać się kolejki pakietów na interfejsach, których obsługa zajmuje trochę czasu. Rosą zatem opóźnienia, które są bardzo odczuwalne w momencie, gdy ktoś lubi sobie pograć w różnego rodzaju gry online. Innym problemem może być sieć P2P, gdzie pojedynczy host z naszej sieci może nawiązywać dziesiątki czy nawet setki połączeń i tym samym zapychać łącze nie dając szansy innym użytkownikom na komfortowe korzystanie z internetu. W obu przypadkach może nam pomóc kształtowanie ruchu sieciowego (Traffic Control), która jest w stanie nadać pakietom odpowiedni priorytet, tak by część z nich nie musiała czekać zbyt długo w kolejce. W tym wpisie przyjrzymy się bliżej temu mechanizmowi.

W linux'ie, kształtowanie przychodzącego ruchu sieciowego stwarza dość poważne problemy. Na dobrą sprawę, obecnie w kernelu nie ma żadnego mechanizmu, który byłby w stanie to zadanie realizować. Istnieją, co prawda, interfejsy IFB ale za ich pomocą jesteśmy w stanie z powodzeniem kształtować jedynie ruch wychodzący. W przypadku pakietów napływających, możemy jedynie ograniczyć im przepustowość. W tym powyższym linku jest wzmianka, że te interfejsy IFB są następcą interfejsów IMQ. Niemniej jednak, ten drugi projekt zdaje się działać, choć nie jest obecnie wspierany przez kernel linux'a. W tym wpisie postaramy się skonfigurować działające interfejsy IMQ, tak, by za ich pomocą skutecznie kształtować ruch przychodzący.

Podczas jednej z aktualizacji systemu został mi zwrócony pewien komunikat. Oświadczał on bowiem, że od jakiegoś czasu nazewnictwo interfejsów sieciowych w systemie uległo zmianie, oraz, że w wersji 10 debiana, ten obecny system nazw nie będzie już wspierany. Rozchodzi się o coś co nazywa się Predictable Network Interface Names, czyli przewidywalne nazwy interfejsów sieciowych. Jako, że aktualne wydanie stabilnego debiana ma numerek 8 i w niedalekiej przyszłości zostanie wydana 9, to przydałoby się już zacząć migrować na ten nowy system nazw. W tym wpisie dokonamy takiej migracji i zobaczymy jakie zmiany musimy poczynić, by nie doświadczyć problemów związanych z tą migracją nazw.

W prehistorycznych czasach, internet był bardzo limitowany. Nie chodzi tutaj o prędkość, która obecnie sięga 100+ mbit/s, a o transfer danych. Świat poszedł już trochę do przodu od tamtego czasu i chyba żaden ISP, który obecnie dostarcza internet stacjonarny, nie narzuca swoim klientom ile danych mogą pobrać i/lub wysłać w konkretnym miesiącu. Problem pojawia się w przypadku internetu mobilnego, który w niedługim czasie prawdopodobnie zapanuje nad światem. Mowa oczywiście o LTE, czyli szerokopasmowym internecie bezprzewodowym. Chodzi generalnie o to, że spora cześć providerów (jak nie wszyscy) limitują transfer danych w tej usłudze. Jest to około 100GB na miesiąc. Może to wydawać się dużo ale trzeba mieć na względzie, że dotyczy to zarówno download'u jak i upload'u. No i oczywiście, dziś wszystko mamy w HD i rzadko kto korzysta z internetu sam. Nawet przeciętna strona www waży już kilka MiB. Przydałoby się zatem wiedzieć ile danych transmitujemy przez sieć każdego dnia, tak by czasem nie doświadczyć problemów związanych z przekroczeniem transferu. W tym wpisie postaramy się pozyskać te informacje i wygenerujemy sobie przyzwoite statystyki transferu przy pomocy narzędzia vnstat .

Bardzo wielu ludzi nie uświadamia sobie faktu, że w przypadku komputerów praktycznie wszystkie dane, z którymi mamy styczność, są zapisane za pomocą dwóch znaków, tj. 0 i 1. Mając to na względzie, nie ma chyba informacji, której by nie można było przesłać przez sieć. Serwer dźwięku, jak sama nazwa wskazuje, jest w stanie odbierać dane zawierają informacje dźwiękowe. Dlatego też jeśli jakiś komputer nie posiada karty muzycznej lub/i nie jest fizycznie podłączony do głośników, to nie stanowi to większego problemu by był on w stanie odtwarzać dźwięk, przynajmniej w tym sensie jakim my to rozumiemy. W tym wpisie sþróbujemy zrealizować przesyłanie dźwięku przez sieć wykorzystując do tego PulseAudio i zobaczymy czy sprawi nam to jakieś problemy.

Sieci bezprzewodowe w obecnych czasach to standard i nie ma chyba miejsca na ziemi gdzie nie dałoby rady ulokować routera WiFi, do którego można by podłączyć szereg urządzeń. Każdy kto próbował konfigurować sieć bezprzewodową na debianie, wie, że może to być bardzo upierdliwe, zwłaszcza jeśli mamy dostęp do wielu AP, które posiadają różne konfiguracje. Wynaleziono, co prawda, automaty, które mają pomagać w ogarnięciu tego całego bezprzewodowego zamieszania, np. network-manager czy wicd ale w przypadku lekkich stacji roboczych, które nie mają wgranego pełnego środowiska graficznego, a jedynie jakiś menadżer okien, np. Openbox, to instalacja tych powyższych narzędzi może zwyczajnie nie wchodzić w grę.

Poniższy wpis ma na celu stworzenie infrastruktury WiFi w oparciu o oprogramowanie freeradius zainstalowane na debianowym serwerze. Projekt zakłada wykorzystanie osobnego urządzenia NAS (AP), w tym przypadku jest to router TP-Link TL-WR1043N/ND v2, na którym jest zainstalowane oprogramowanie OpenWRT. W oparciu o te dwie maszyny spróbujemy skonfigurować protokół WPA2 Enterprise z obsługą trzech metod uwierzytelniania, tj. EAP-TLS, EAP-TTLS oraz PEAP (v0) . Będziemy również potrzebować kilku certyfikatów (w tym CA), bez których to pewne mechanizmy mogą nie działać.

Retransmisja pakietu w przypadku sieci opartych na protokołach TCP/IP nie jest niczym niezwykłym. Oczywiście, pozostaje kwestia samego realizowania tego przedsięwzięcia ale generalnie rzecz biorąc, systemy linux'owe mają szereg opcji w kernelu, które możemy sobie dostosować konfigurując tym samym, to w jaki sposób nasz system reaguje na zjawisko utraty pakietów podczas ich przesyłu między dwoma punktami sieciowymi.

Przerabiając analizę pakietów sieciowych, dotarłem w końcu do sieci bezprzewodowych, a te różnią się nieco od tych swoich przewodowych kuzynów. Generalnie rzecz biorąc nie będę tutaj opisywał samej analizy pakietów, które sobie przemierzają eter w pobliżu naszych urządzeń WiFi, a jedynie poruszę kwestię pakietów Beacon, które są rozsyłane przez punkty dostępowe w pewnych odstępach czasu.