Podczas procesu kompilacji pakietów często zdarza się tak, że brakuje jakichś zależności, bez których dany pakietów nie chce się nam zbudować. W większości przypadków, system powinien nam podpowiedzieć jaki pakiet powinniśmy doinstalować. Nie zawsze jednak będzie to takie oczywiste i jedyne co nam zostanie zwrócone, to ścieżka danego pliku lub tylko jego nazwa. Nawet jeśli nie kompilujemy programów, to podczas zwykłego użytkowania komputera możemy potrzebować odnaleźć pakiet, który zawiera pewien określony plik binarny czy konfiguracyjny. Jak zatem odnaleźć się w gąszczu plików i katalogów by efektywnie ustalić pakiet, który zawiera interesujące nas pliki?

MTU (Maximum Transmission Unit) to maksymalna długość pakietu jaki może zostać przesłany przez sieć. Może ona wynosić do 64KiB ale większość punktów sieciowych, takich jak routery, wymusza o wiele mniejsze rozmiary pakietów. Domyślna wartość MTU dla protokołu Ethernet to 1500 bajtów, oczywiście bez nagłówka warstwy fizycznej, który ma dodatkowe 14 bajtów. Czasami te standardowe ustawienia mogą powodować problemy w przypadku pewnych konfiguracji sieci i gdy ich doświadczamy, przydałoby się zmienić rozmiar MTU przesyłanych pakietów.

O znacznikach czasu (timestamp) wspominałem już raz w ramach omawiania mechanizmu jakim jest bufor połączenia, a konkretnie rozchodziło się o skalowanie okien TCP. Generalnie rzecz biorąc, przy wyższych prędkościach, rzędu 1 gbit/s, nie ma innej opcji jak skorzystanie z opcji znaczników czasu, które są niejako rozszerzeniem czegoś co widnieje pod nazwą numery sekwencyjne . Z jednej strony może i mamy możliwość implementacji łącz o większej przepustowości ale z drugiej te znaczniki czasu w pakietach TCP mogą zagrozić bezpieczeństwu stacji roboczej.

Jeśli zastanawialiście się czym są numery sekwencyjne i potwierdzeń w strumieniach protokołu TCP, to nie jesteście jedyni, którym to zagadnienie spędza sen z powiek. Dlatego też poniżej postanowiłem opisać najdokładniej jak umiem proces jaki zachodzi przy przesyłaniu danych z jednego punktu sieciowego na drugi. Bez zaprzęgnięcia sniffera sieciowego raczej nie da się zrozumieć tego tematu i poniższy przykład zawiera szereg odwołań do programu wireshark.

Jakiś czas temu opisywałem jak zaprojektować swój własny firewall, wobec czego postanowiłem nieco bardziej pochylić się nad zagadnieniem stanów połączeń i je dokładniej przeanalizować. Ten wpis dotyczy głównie protokołu TCP, bo ten UDP jest bezpołączeniowy, więc nie ma tam żadnych stanów. Dodatkowo opiszę tutaj poszczególne flagi, które mogą zostać ustawione w pakietach zmieniając tym samym stan połączenia.

Czasem niektórzy ISP z jakiegoś bliżej nieokreślonego powodu blokują dostęp do internetu hostom zlokalizowanym za routerem czy innym komputerem udostępniającym połączenie sieciowe. ISP zwykle stara się blokować konkretną wartość pola TTL, która jest ustawiana w każdym przesyłanym przez nasze maszyny pakiecie. Innym sposobem zablokowania możliwości udostępniania internetu jest ograniczenie wartości pola TTL do jednego hopa wszystkim pakietom dochodzącym do routera od strony ISP. Jeśli mamy nieszczęście trafić na takiego providera, to warto wiedzieć, że przy pomocy iptables możemy ustawić/podbić/zmniejszyć czas życia pakietów, które docierają do routera zarówno od strony LAN jak i WAN i tym samym bez większego trudu możemy sobie poradzić z tą blokadą.

Każdy z nas ma router w domu, który potrafi rozdzielić sygnał na szereg komputerów w naszej sieci lokalnej. Jeśli z jakichś powodów nie chcemy posiadać w domu tego cuda techniki i chcielibyśmy mieć możliwość udostępniania połączenia internetowego za pośrednictwem innego komputera, to nic nie stoi nam na przeszkodzie by to zrobić. Taki komputer stacjonarny niczym się nie różni od routera, no może za wyjątkiem poboru prądu.

Wiele linux'owych klientów torrent'a umożliwia ładowanie zewnętrznej listy z zakresami adresów IP i ta lista ma służyć jako swego rodzaju filtr połączeń chroniący nas przed różnego rodzaju organizacjami, które mogą zbierać i przetwarzać informacje na temat naszego IP i tego, co on porabia w sieci p2p. Oczywiście, kwestia czy korzystać z takiego typu rozwiązania jest bardzo dyskusyjna i wiele osób jest zdania, że to tak naprawdę w niczym nie pomoże, a wręcz nawet przyczynia się do samounicestwienia sieci p2p. Także taki filtr może czasem przynieść więcej szkody niż pożytku, zwłaszcza gdy się go używa lekkomyślnie, czyli na zasadzie, że ten który blokuje więcej adresów IP musi być lepszy. Poniżej zostanie opisane rozwiązanie zakładające wykorzystanie rozszerzenia ipset , które w połączeniu z iptables da nam w pełni działający filtr połączeń p2p (coś na wzór popularnego oprogramowania PeerGuardian), dzięki któremu będziemy w stanie wyciąć dowolny ruch i to nie tylko przy korzystaniu z różnych klientów torrent, np. qbittorrent, ale także i przy zwykłym przeglądaniu stron www.

Jeśli próbowaliśmy odnaleźć odpowiednią ścieżkę do urządzenia usb w linuxowym drzewie katalogów, to wiemy, że nie jest to łatwe zadanie. Mamy, co prawda, do dyspozycji polecenie lsusb ale ono nie daje nam precyzyjnych informacji na temat tego gdzie dokładnie w katalogu /sys/ znajdują się określone urządzenia. Na necie natrafiłem na FAQ dotyczący tego zagadnienia i postanowiłem napisać kilka zdań o tym jak zinterpretować ciągi typu 2-1.1.2:1.1 oraz jakie to może być urządzenie.

Kernel w linux'ie odcina zasilanie urządzeniom podpiętym do portów USB jeśli sterownik wspiera tego typu możliwość oraz samo urządzenie nie jest używane przez pewien okres czasu. W taki oto sposób, jeśli podłączymy, np. zewnętrzną klawiaturę USB do laptopa, możemy zaobserwować, że przy pisaniu tekstu gubiony jest zwykle pierwszy znak. Może i klawiatura po przyciśnięciu klawisza wyszła ze stanu bezczynności ale system nie zareagował na tyle szybko by złapać sygnał przycisku. Na necie ludzie piszą, że jest to problem niekompatybilności urządzeń i tego typu sytuacja nie powinna się zdarzać. Jeśli jednak natrafiliśmy na klawiaturę czy myszę, która cierpi z powodu automatycznego zawieszania jej zasilania, możemy wyłączyć ten ficzer zupełnie.