Ja zbytnio się nie nadaję na programistę ale czasem jakieś trzeciorzędne skrypty nawet potrafię napisać. Problem ze skryptami jest taki, że mogą one nie do końca działać jak należy. Zwykle w takich przypadkach, skrypt zwraca jakiś kod wyjścia. Z reguły też jest on inny od 0, który z kolei oznacza, że skrypt został wykonany prawidłowo. Załóżmy teraz, że wywołujemy szereg poleceń. Każde z nich przekierowuje swoje wyjście na wejście innego polecenia przy pomocy znaku | (pipe) . Jak w takim przypadku ustalić czy wszystkie z tych poleceń w łańcuchu wykonały się poprawnie? W tym wpisie postaramy się odpowiedzieć na to pytanie.

Każdy bardziej zaawansowany administrator sieci prędzej czy później będzie chciał wdrożyć na swoim routerze wyposażonym w firmware OpenWRT pewien mechanizm QoS umożliwiający kształtowanie ruchu sieciowego. Ci, którzy się za ten temat zabierali, wiedzą, że nie jest on prosty w realizacji. Zwłaszcza, gdy chce się cały ten system zarządzania pakietami skonfigurować od podstaw przy pomocy narzędzi takich jak iptables , tc oraz ip . Z tego też względu OpenWRT umożliwia nam nieco prostszą w konfiguracji alternatywę polegającą na zainstalowaniu narzędzi zawartych w pakietach wshaper , qos-scripts lub sqm-scripts . Trzeba przy tym pamiętać, że mechanizm, który zostanie stworzony z wykorzystaniem jednego z tych w/w pakietów nie będzie tak elastyczny jak przy ręcznej konfiguracji od podstaw. Niemniej jednak, w tym artykule postaramy się ogarnąć kształtowanie ruchu przy pomocy tych pakietów.

W standardowej konfiguracji OpenWRT, hosty łączące się za pomocą sieci bezprzewodowej jak i tej przewodowej są spięte razem za pomocą mostka (bridge) i tworzą jedną sieć lokalną. Nie ma w tym nic dziwnego, bo przecie chcemy, aby komunikacja między wszystkimi hostami w sieci LAN odbywała się bez większych przeszkód. Przynajmniej takie jest standardowe podejście przy konfiguracji sieci domowej. Niemniej jednak, w pewnych przypadkach istnieje potrzeba oddzielenia maszyn, które nawiązują połączenie za pomocą sieci WiFi od tych, które łączą się przewodowo. Generalnie chodzi o różne adresy, które zostaną przypisane sieciom LAN i WLAN. Rozwiązanie, które zostanie opisane w tym artykule jest podobne do tworzenia bezprzewodowej sieci gościnnej (guest WLAN), z tą różnicą, że w tym przypadku będziemy mieli do czynienia tylko z jedną siecią WiFi (tzw. Routed AP).

Routery WiFi zwykle oferują jedną sieć bezprzewodową, do której użytkownicy mogą się łączyć po podaniu nazwy ESSID oraz hasła. W przypadku znanych nam osób chcących korzystać z udostępnianego przez nas AP, taka sieć powinna nam w pełni wystarczyć. Problem jednak zaczyna się w przypadku tych użytkowników, którym chcemy zezwolić na dostęp do naszej sieci WiFi ale nie darzymy ich zbytnio wysokim kredytem zaufania. By ten problem rozwiązać, w OpenWRT możemy skonfigurować mechanizm zwany "guest WLAN", czyli bezprzewodowa sieć gościnna. W tym artykule zobaczymy jak odseparować od siebie hosty w sieci LAN od tych w sieci gościnnej.

Strefa zdemilitaryzowana (DMZ, demilitarized zone) to taki mechanizm, który ma na celu poprawę bezpieczeństwa usług w sieci lokalnej. Generalnie chodzi o podział sieci na kilka mniejszych podsieci i oddzielenie ich od siebie fizycznie lub logicznie. W OpenWRT możemy wydzielić taką strefę DMZ przy pomocy VLAN'ów. Z kolei odpowiednio skonfigurowany firewall odseparuje nam tę strefę od pozostałych maszyn pracujących w sieci LAN. W taki sposób nawet w przypadku włamania mającego miejsce w strefie DMZ, maszyny w pozostałych segmentach sieci będą bezpieczne. W tym wpisie postaramy się skonfigurować strefę zdemilitaryzowaną na routerze wyposażonym w firmware OpenWRT.

Github to serwis, w którym użytkownicy mogą pracować wspólnie nad różnymi projektami utrzymywanymi w systemie kontroli wersji GIT. Konto w w/w serwisie może być łakomym kąskiem dla przestępców, zwłaszcza gdy uczestniczymy w dość rozbudowanych projektach i przyczyniamy się do ich tworzenia w dużym stopniu. Z tego powodu github implementuje rozwiązania, które mają na celu poprawić bezpieczeństwo naszej pracy. Mamy już uwierzytelnianie dwuetapowe, obsługę kluczy SSH ale nadal brakowało odpornego systemu, który by uwierzytelnił osoby współdziałające z nami. Chodzi o to, że wszelkie zmiany w repozytorium GIT muszą być przez kogoś poczynione. Każdy commit ma zatem swojego właściciela ale my nigdy nie mamy pewności co do tego, kto tak naprawdę tej zmiany dokonał. Dlatego też github umożliwił ostatnio podpisywanie tagów i commit'ów przy pomocy kluczy GPG. To właśnie temu tematowi będzie poświęcony niniejszy wpis.

Dzisiaj system plików jednej z partycji mojego głównego dysku uległ awarii z niewiadomych przyczyn. Dałbym sobie nawet głowę uciąć, że wszystkie partycje zostały poprawnie odmontowane podczas wyłączania maszyny. Niemniej jednak, z jakiegoś powodu podczas startu systemu, ten wyrzuca szereg komunikatów dotyczących głównego systemu plików, tj. / . Sam komunikat brzmi mniej więcej tak: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY . Oznacza to, że błędy w systemie plików nie są łatwe do naprawy i wymagana jest nasza ingerencja w ten proces. Przy sprawdzaniu systemu plików w poszukiwaniu błędów przy pomocy fsck.ext4 można było dostrzec min. taką wiadomość: Inode 556975 has corrupt extent header . Co ona tak naprawdę oznacza i czy damy radę wybrnąć z tej sytuacji bez szwanku?

Network File System) to sieciowy system plików, za pomocą którego maszyny mające na pokładzie system operacyjny linux, w tym tez OpenWRT, są w stanie udostępniać pliki w sieci. Zatem NFS to głównie domena linux'ów. W przypadku windowsów można korzystać z protokołu SMB (samba). Sposób udostępniania zasobów przy pomocy tego sieciowego systemu plików jest bardzo podobny do tego, który jest realizowany w przypadku protokołu SSHFS. Zasadniczą różnicą między NFS i SSHFS jest brak szyfrowania komunikacji. W warunkach domowej sieci, ta cecha raczej nie stanowi większego problemu. Poza tym, trzeba też brać pod uwagę fakt, że szyfrowanie znacznie obciążyłoby router, co przełożyłoby się na spadek prędkości transferu. W tym wpisie zobaczymy jak na routerze z OpenWRT zaimplementować protokół NFS i udostępnić za jego pomocą zasoby w sieci lokalnej.

Usługa FTP jest w miarę wygodnym rozwiązaniem w przypadku, gdy chcemy korzystać z zasobów udostępnianych przez router zarówno na linux'ach jak i na windowsach. Jedyne czego potrzebujemy to kawałek przeglądarki albo jakiegoś klienta FTP. W tym protokole nie ma też znaczenia system plików, w którym znajdują się udostępniane pliki. Jedyne co nas interesuje, to postawienie serwera na routerze i podanie klientom namiarów na niego. W OpenWRT możemy do tego celu zaprzęgnąć vsftpd . W tym wpisie pokażę jedynie jak tego typu usługę uruchomić na domowym routerze WiFi i jak ją wstępnie skonfigurować. Wszelkie kwestie techniczne związane z działaniem samego serwera FTP jak i jego wszystkich parametrów już opisywałem przy okazji wdrażania vsftpd w dystrybucji debian. Zachęcam zatem do zapoznania się również z tym podlinkowanym wpisem.

Bezprzewodowy router WiFi to w miarę proste urządzenie, które w zasadzie realizuje kilka podstawowych aspektów pracy sieci domowej. Wielu użytkownikom jednak jest nieustannie potrzebna jakaś nowa funkcjonalność, której oryginalny firmware producenta nie oferuje. Dlatego też mamy do dyspozycji OpenWRT będący minimalistyczną formą bardziej rozbudowanej dystrybucji linux'a. Może i OpenWRT daje nam możliwość zaawansowanej konfiguracji naszej sieci ale tego typu opcja powoduje też szereg problemów. Chodzi o to, że kernel dynamicznie tworzy nazwy dla wszystkich podłączanych urządzeń do routera. W dużych dystrybucjach linux'a do ogarnięcia tych nazw wykorzystywany jest UDEV. W przypadku OpenWRT też możemy skorzystać tego mechanizmu. Jeśli jednak mamy niewiele miejsca na pamięci flash routera, to możemy też skorzystać ze zdarzeń hotplug. W tym wpisie postaramy się przepisać nazwy pendrive/dysków twardych oraz modemów USB (LTE), tak by ich kolejność podłączania do routera nie stwarzała problemów w konfiguracji.