Niestety najczęściej nie sprawdzą się w zastosowaniach domowych. Artykuł prawdopodobnie może nie zostać w pełni zrozumiały dla każdego chodź postaram się aby tak było. Zapraszam tym samym do trzeciej części poradnika o bezpiecznej sieci Wi-Fi.

AP Isolation

Po uruchomieniu tej funkcji żadne z urządzeń podłączonych do tej samej sieci Wi-Fi nie będą się wzajemnie widziały. Funkcje warto zastosować głównie w momencie, gdy będziemy chcieli stworzyć publiczny hotspot lub sieć dla gości. W domu ta funkcja ma swoje zastosowanie tylko w momencie, kiedy nie łączycie się z innym urządzeniem w sieci Wi-Fi. Pewnie większość osób powie – nie. Pamiętajcie, że dotyczy to również urządzeń typu drukarka czy konsola. Czyli jeśli macie PS4 podłączone przez Wi-Fi i chcecie zagrać w jedną z gier serii Playstation Link to również urządzenia nie będą się wzajemnie widziały, przez co nie pogracie.

Filtrowanie adresów MAC

Adres MAC to nic innego, jak unikalny identyfikator karty sieciowej waszego urządzenia. Dzięki niemu możemy identyfikować każde z urządzeń podłączonych do sieci. Dlatego też lata temu producenci sprzętu komputerowego wpadli na pomysł, aby przy pomocy filtrowania adresów pozwalać (lub blokować) konkretne urządzenie w sieci. Po uruchomieniu tej funkcji do sieci będą mogły podłączyć się tylko te urządzenia, które ręcznie zostały wpisane na listę. Dzięki czemu, jak się pewnie domyślacie, nawet, gdy ktoś będzie znał hasło do Waszej sieci Wi-Fi nie połączy się z nią. Router automatycznie rozłączy urządzenie, którego brak na liście lub znajduje się na czarnej liście.

Nie sugeruj się tym screenshotem

Sugerując się tylko tym screenshotem możecie nie znaleźć tej funkcji. Zarówno w routerach TP-Link, jak i Linksys, Cisco czy nawet Xiaomi tę funkcję obsługuje się nieco inaczej i wygląda inaczej. W przypadku tego routera można to zrobić jak na screenie. Czyli ustawiając statyczne adresy IP w serwerze DHCP i uruchamiając „Kontrole dostępu” zaznaczyć „Białą listę” i wtedy połączą się z siecią tylko te urządzenia, które znajdują się na tej liście. Można również zaznaczyć czarną listę, wtedy wszystkie urządzenia będą dopuszczane oprócz tych wpisanych na czarną listę. Tak jest w przypadku tego routera. W Twoim routerze może być to zupełnie inne. Jak i nie będzie się nazywać „Access Control” a np. jak w jednym z znanych mi routerów Cisco – „Wireless Mac Filter”.

Wysokie podnoszenie bezpieczeństwa – czy na pewno?

Rozwiązanie w mojej opinii w pewnym stopniu wysoce podnosi bezpieczeństwo, lecz bywa uciążliwie. Przed podłączeniem nowego urządzenia do sieci będziecie musieli ręcznie wpisać adres MAC tego urządzenia. Tak nawet drukarki, konsoli czy wieży. Dlatego to rozwiązanie często stosuje się w firmach, aby pracownicy mogli podłączać do sieci służbowy komputer, lecz nie prywatny smartphone. Oczywiście można stosować to rozwiązanie również w domu. Uciążliwe i tylko dla osób, które są nieco bardziej zaawansowane. W warunkach domowych uważam to w większości przypadków za zbędne rozwiązanie.

W pewnym stopniu

Dlaczego w pewnym stopniu? Bo jak wspomniałem przy okazji drugiej części poradnika. Nie ma rozwiązania, którego nie da się obejść. To że w routerach można klonować adres MAC nie jest chyba dla nikogo zaskakujące. W końcu wielu z dostawców sieci identyfikuje swoich klientów właśnie poprzez DHCP na podstawie adresu MAC podanego na umowie. Lecz adres MAC można również zmienić w urządzeniu.

Udowodnij!

W macOS potrzeba do miany adresu MAC kilka komend terminala. W systemach rodziny Windows jest jeszcze prościej, gdyż wystarczy w ustawieniach karty sieciowej znaleźć odpowiedni parametr.

Domyślacie się pewnie, że w tym miejscu należy wpisać w systemie szesnastkowym dowolnie wymyślony adres MAC. Wpisujemy go bez znaku myślnika (-). Zatwierdzamy zmianę i gotowe. Temu tematowi poświeciłem osobny poradnik, który pojawi się niebawem.

Czyli co mogłoby się wydarzyć?

Jeśli uruchomilibyście funkcje filtrowanie adresów MAC. Dopisalibyście do dopuszczonych urządzeń adresy MAC swoich urządzeń. To jest możliwa następująca metoda ataku. Ktoś mógłby zacząć „podsłuchiwać” Waszą sieć np. przy pomocy programu Wireshark i mógłby zdobyć adres MAC komputera, który łączy się się z siecią. Następnie wystarczyłoby, że taki adres MAC ustawiłby w swoim urządzeniu, aby również móc się połączyć z Waszą siecią. Uprzedzam – wiem, że jest to nieco naciągana metoda ataku, jednak możliwa. Najpierw musimy zdobyć adres MAC urządzenia i mieć pewność, że jest ono dopisane do serwera DHCP. Posiadać lub podsłuchać hasło do sieci Wi-Fi. Trzeba odpowiednią ilość czasu poświęcić na podsłuchiwanie takiej sieci. Wiem, lecz chciałem tylko zwrócić uwagę że nie ma rozwiązań idealnych i nawet tę funkcję można obejść na swój skomplikowany sposób.

Bezpieczna sieć Wi-Fi – To wszystko?

Obie z przedstawionych funkcji prawdopodobnie nie będą przydatne Wam w domu. AP Isolation ze względu na to iż urządzenia nie będą się widziały. Filtrowanie adresów MAC przez swoją uciążliwość. W mojej opinii funkcje te sprawdzą się głównie w zastosowaniach firmowych, lecz nie wykluczam tego, że ktoś z Was z nich nie skorzysta. Wiem, że nie opisałem w ramach tego poradnika wielu innych funkcji, jak chociażby kontrola rodzicielska czy QoS. Jednak celem tego poradnika było trafienie do jak największej grupy zainteresowanych maksymalnie prostym językiem i funkcjami. Wydaje mi się że to nie było możliwe. Mam nadzieję, że chodź część z czytelników nauczyła się czegoś lub została zainteresowana tematem bezpieczeństwa sieci. Jak wspominałem w każdej części tak wspomnę i tu. W mojej opinii jeśli nie podajecie każdemu hasła. Od czasu – do czasu kontrolujecie kto łączy się z Waszą siecią Wi-Fi i macie mocne oraz unikalne hasło – nie ma większych powodów do obaw. Czekamy na Wasze komentarze, jakie jeszcze poradniki chcielibyście, aby znalazły się w TestHub.

obrazek tytułowy: pexels.com | screenshot: autora wpisu

Artykuł Bezpieczna sieć Wi-Fi: AP Isolation i filtrowanie adresów MAC (część 3/3) pochodzi z serwisu TestHub.pl.

D-Link DWR-921 nadaje się do kosza

Redaktorzy portalu niebezpiecznik.pl bardzo często z racji swojej specyfiki pracy ostrzegają przed różnymi poważnymi lukami bezpieczeństwa. Tak jest i w tym przypadku. Odezwała się do nich osoba, której jednej z nocy ktoś nabił całkiem sporą kwotę na rachunku poprzez SMS-y premium, chodź na takowe były ustawione limity.

Zacznij od początku tej historii

W okolicach godziny 2:26 z routera D-Link DWR-921 został wysłany SMS na rosyjski numer telefonu. Następnie przyszła cała seria SMS-ów od operatora Orange, w których poinformowano o zmianach limitów na usługi premium. Początkowo zmiana wprowadzała limit do 300 zł. Później limit ktoś zwiększył aż do 400 zł. Następnie operator Orange wysłał SMS-a, że karta SIM zostaje zablokowana. Powodem było przekroczenia kwoty 1000 zł. Informator niebezpiecznika z bilingu dowiedział się iż w sumie wysłano 35 SMS-ów na numery premium.

D-Link bagatelizuje sprawę?

Jak dowiecie się z strony producenta router D-Link DWR-921 nie ma już wsparcia. Chodź luki są mu znane. Już wcześniej były wskazane przez jednego z polskich badaczy bezpieczeństwa. D-Link twierdził, że badacz trochę nadużywał słowa „zdalny” przy informowaniu o podatnościach routera na ataki, bo ich wykorzystanie było możliwe po połączeniu się przez LAN. Jak pokazuje powyższy przypadek chyba producent nie jest do końca sam świadom w jakim stopniu router jest „dziurawy”. Dodatkowo jak podkreśla redaktor Marcin Maj – sam operator Orange już w ubiegłym roku informował o tym, że router nie jest bezpieczny i warto go zmienić.

Poniżej komentarz o sprawie Rzecznika Orange – Wojciecha Jabczyńskiego:

„O zagrożeniach wynikających z używania modemu D-Link DWR-921 informowaliśmy naszych klientów na stronie cert.orange.pl w październiku 2018 roku. Zalecaliśmy jego wymianę. Według informacji producenta modem już wtedy nie był wspierany, także w zakresie poprawek bezpieczeństwa. Urządzenie nigdy nie było sprzedawane w ofercie Orange Polska.

Każdy klient może założyć blokadę usług Premium Rate poprzez aplikację Mój Orange lub BOK. Zawsze też może złożyć reklamację, którą rozpatrzymy po przeanalizowaniu jego sprawy. Każdą reklamację rozpatrujemy indywidualnie.”

Routery powinny mieć datę ważności?

Redaktor niebezpiecznika zwrócił również uwagę na jeszcze jedną ciekawą sprawę. Jako iż w 2018 roku w Niemczech rozmawiano na temat ciekawego pomysłu, aby na każdym z routerów umieszczać datę ważności. Wtedy sam producent do dnia umieszczonego na opakowaniu miałby oferować wsparcie. Byłaby też to dobra informacja dla konsumentów do kiedy swój router mogą uważać za bezpieczny.

Pełny artykuł dostępny TUTAJ.

Artykuł Masz w domu router D-Link DWR-921? Koniecznie zmień urządzenie pochodzi z serwisu TestHub.pl.

Ukrycie SSID: niewidoczna sieć Wi-Fi

Ukrywanie SSID to funkcja, która nic nie wnosi do bezpieczeństwa. Powiedziałbym więcej: wprawna osoba szperająca w internecie znajdzie kompleksowy poradnik, jak taką sieć zobaczyć w warunkach firmowych lub domowych. Poza zbędnym narzekaniem reszty domowników lub pracowników firmy, że źle wpisują nazwę sieci i się nie łączy, nic ta funkcja nie wnosi bezpośrednio do bezpieczeństwa sieci.

Nie zrozumcie też mnie źle – nie twierdzę, że to zbędna funkcja. Uważam jednak, że jest przydatna tylko wtedy, gdy z jakiegoś powodu nie chcemy, aby konkretna sieć rzucała się w oczy. W jednej z firm, w której pracowałem, stosowano to rozwiązanie. Sieć Wi-Fi dla wszystkich pracowników była widoczna, a sieć typowo dla pewnej grupy pracowników była celowo ukryta. Według mnie ukrywanie do bezpieczeństwa nic nie wnosi prócz tego, że na pierwszy rzut oka sieć nie będzie widoczna dla wszystkich.

Przycisk WPS

W warunkach domowych to bardzo umilająca podłączanie się do sieci funkcja. Przy pomocy jednego kliknięcia lub podania wygenerowanego PIN-u łączymy się z siecią. Spotkałem się z opiniami, że WPS nie jest dobrze zabezpieczony przed atakami słownikowymi, czyli atakiem typu brutal force. Pewnie biorąc pod uwagę PIN składający się z samych cyfr, można się z tym zgodzić. W zastosowaniach firmowych ta funkcja jest zwykle wyłączana, traktowana jako luka bezpieczeństwa sieci. W zastosowaniach domowych podchodzę do tego tak: jeśli macie taką potrzebę, zostawcie włączoną. Osobiście nie korzystam z tego przycisku, ponieważ router stoi w łatwo dostępnym miejscu, a nie chciałbym, żeby ktoś prostym trikiem połączył się z moją siecią bez mojej zgody.

Firewall i SPI Firewall

Zapora sieciowa w routerze głównie odpowiada za obronę przed atakami DDoS. Sam atak DDoS to nic innego jak wykorzystanie w 100% zasobów danej sieci / serwera do tego, aby go unieruchomić. Takie ataki raczej nie zdarzą się na użytkowników domowych, stąd domyślnie funkcja pozostaje wyłączona.

SPI Firewall to coś nieco innego. Tłumacząc pokrótce, skanuje nagłówki pakietów przechodzących przez router. Weryfikuje w ten sposób, czy dane połączenie powinno zostać dopuszczone czy odrzucone. Domyślnie funkcja jest uruchomiona i warto zadbać, aby tak pozostało. Jeśli chcecie poznać więcej szczegółów dotyczących zapory, odsyłam do świetnego artykułu Krzyśka.

Czy sieć Wi-Fi może być w 100% bezpieczna?

Wszystko leży tak naprawdę w naszych rękach. Nie ma w mojej opinii osoby i produktu, którego nie da się przechytrzyć. Czy to odpowiednimi sztuczkami technicznymi, czy też socjotechniką. Jak wspominałem przy okazji pierwszej części poradnika, grunt to nie popadać w paranoję. Jeżeli jesteśmy zwykłym Kowalskim, mało prawdopodobne, że ktoś będzie miał powód, żeby włamać się do naszej sieci Wi-Fi. W 99% prędzej możena spodziewać się innych metod oszustwa, np. phishingu. Jeżeli chcecie więcej informacji dotyczących okradania przez internet, zapraszam do obejrzenia filmu Szafy.

Bezpieczna sieć Wi-Fi

Część 1. Bezpieczna sieć Wi-Fi: podstawy

Cześć 3. 42657a706965637a6e61207369651072057692d46693a2041502049736f6c6174696f6e2c20426c61636b6c69737420692066696c74726f77616e6965206164726573f377204d4143

Jaka jest nazwa części trzeciej? Czekamy na wasze komentarze.

grafika tytułowa: unsplash.com

Artykuł Bezpieczna sieć Wi-Fi: ukryte SSID, przycisk WPS i Firewall (część 2/3). pochodzi z serwisu TestHub.pl.

Ostatni  odcinek skończył się pełnym sukcesem i wreszcie router ma dostęp do Internetu. Czas zatem na ważny moment. Z bliżej mi nieznanych przyczyn urządzenia, które kupowałem nawet całkiem niedawno, mają bardzo starą wersję EdgeOS. Wręcz prehistoryczną. W momencie pisania tego tekstu aktualna wersja to 1.9.7 + hotfix 4 (hotfix’y to zupełnie nowy wynalazek, który pojawił się z wersją 1.9.7),  tymczasem na routerze znajdziemy:

Tak, dobrze widzicie. Wersję z połowy 2013 roku, w routerze, który opuścił fabrykę w 2017 roku. Przy okazji, coraz częściej będę od Was oczekiwał samodzielności, więc albo dostaniecie zrzut ekranu i komendę, będziecie musieli odczytać z niego samodzielnie, albo podam Wam polecenie (szczególne jeśli będzie złożone), ale efekt jego działania zobaczycie dopiero jak sami z niego skorzystacie. Wracając zatem do aktualizacji.

Szukamy najnowszej wersji

Celem sprawdzenia najnowszej wersji udajemy się na stronę WWW firmy Ubiquiti Networks i wybieramy kolejno DOWNLOADS w górnym menu, z linii produktów EdgeMAX, a z menu po lewej model, czyli w moim wypadku jest to EdgeRouter Lite.

Po wybraniu wersji, do której chcemy zaktualizować system routera, wybieramy ikonę strzałki po prawej stronie, w kolumnie file, zatwierdzamy licencję EULA jeśli się pojawi (nie zawsze) i… nie, nie. Nic nie pobieramy. Klikamy na przycisk COPY URL.

Oczywiście, że CLI

Jeśli spodziewaliście się pobierania pliku na swój komputer, wgrywania go przez FTP’a, to nic z tych rzeczy. Postawcie się w roli administratora, który musi to zrobić zdalnie, na urządzeniu, które może stać setki albo i tysiące kilometrów od niego. Przecież po to właśnie jest linia komend, by służyła w takiej sytuacji pomocą. Wydajemy zatem polecenie add system image i jeśli korzystacie z programu PuTTY to kliknięciem prawego klawisza myszy wklejacie zawartość schowka lub korzystacie ze skrótu, jaki przewidział producent aplikacji, z której korzystacie. W efekcie wasze polecenie dla wersji 1.9.7 hotfix 4 powinno wyglądać tak:

• add system image https://dl.ubnt.com/firmwares/edgemax/v1.9.7/ER-e100.v1.9.7+hotfix.4.5024004.tar

Po zatwierdzeniu komendy rozpocznie się pobieranie nowej wersji oprogramowania, a jego postęp będzie na bieżąco aktualizowany:

Po pobraniu oprogramowania zostanie ono sprawdzone na wypadek ewentualnych błędów i jeśli takowe nie wystąpiły nastąpi aktualizacja zakończona stosownym komunikatem:

Zwróćcie uwagę, że aktualizacji dokonujemy z trybu operacyjnego a nie konfiguracyjnego! Oczywiście nowa wersja systemu zostanie wczytana po ponownym uruchomieniu routera, a zatem wydajemy polecenie reboot, które należy potwierdzić.

Sprawdzam

Korzystając z poznanej już na wstępie komendy, sprawdzamy efekt naszych działań:

Widać, że nowa wersja została zainstalowana, jest aktualnie uruchomiona (running boot) i zostanie również wczytana przy kolejnym uruchomieniu routera (default boot). Co istotne, na wszelki wypadek stara wersja również jest dostępna na FLASH-u.

Zadanie domowe: jak zmusić router, by przy kolejnym uruchomieniu ponownie załadował stary obraz systemu? Mała podpowiedź: pamiętajcie o znaku zapytania i zwróćcie uwagę, że w trybie operacyjnym też jest dostępna komenda set. Dalej jest już z górki

Kopia zapasowa to podstawa

Należy mieć na uwadze, że migracja konfiguracji jest jednokierunkowa. To znaczy jeśli podnosimy wersję EdgeOS, to konfiguracja zostanie „przepisana” z uwzględnieniem zmian jakie zaszły w składni. Operacja ta nie jest odwracalna, dlatego zawsze przed aktualizacją warto wykonać kopię zapasową konfiguracji, by móc do niej wrócić, jeśli zajdzie potrzeba przywrócenia starej wersji oprogramowania. Niestety z tego co wiem, nie istnieje równie prosta metoda pobrania pełnej kopii zapasowej z CLI i do tego celu należy posłużyć się GUI. Co nie znaczy, że dla chcącego nic trudnego. Tym bardziej ambitnym podpowiem, że plik konfiguracyjny znajdą w lokalizacji /config/config.boot. Inna opcja to wyświetlenie bieżącej konfiguracji w postaci zestawu poleceń konfiguracyjnych, które można w prosty sposób skopiować, czy to między urządzeniami, czy do pliku. Służy do tego komenda show configuration commands.

To jeszcze nie koniec

Co prawda temat „podstaw” wyczerpaliśmy, nie znaczy to jednak końca przygód z routerami Ubiquiti. Wręcz przeciwnie, wiele jeszcze zostało do omówienia, ale będą to już tematy nieco bardziej zaawansowane, jak konfiguracja firewall’a, VLAN’y, VPN’y… Będziemy korzystać zarówno z CLI, jak i graficznego interfejsu użytkownika (GUI). I tak dalej. Także zaglądajcie regularnie na TestHub.pl po kolejne poradniki. I piszcie w komentarzach, co Was szczególnie interesuje.

Artykuł Podstawy pracy z interfejsem linii komend (CLI) systemu EdgeOS – część 3 pochodzi z serwisu TestHub.pl.

Zanim przejdziemy dalej, taka mała uwaga organizacyjna. Jeśli jakieś zagadnienia są dla Was obce lub niejasne i wymagają objaśnienia, zadawajcie pytania w komentarzach, ale zachęcam też do samodzielnego poszukiwania odpowiedzi w Internecie. Tak zdobyta wiedza daje dużą satysfakcję i zostaje na dłużej. Dajcie też znać, czy poruszane zagadnienia są dla Was ciekawe.

Czas na show!

Z lektury pierwszej części wiecie już, jakie są tryby pracy CLI oraz jak przejść do edycji konfiguracji, zatwierdzić zmiany czy zapisać je w konfiguracji startowej. A jak wyświetlić podstawowe informacje o urządzeniu, czyli sprawdzić jego konfigurację czy adresację interfejsów? Służy temu komenda „show” z dodatkowymi opcjami. I tak bieżącą konfigurację wyświetla polecenie „show configuration”. Poniżej wynik tej komendy na routerze EdgeRouter Lite z konfiguracją domyślną (czyli po wyjęciu z pudełka lub przywróceniu ustawień fabrycznych).

Jak widać, konfiguracja przywodzi na myśl jakiś język programowania i początkowo może wydawać się straszna, ale z czasem nie będzie miała dla was żadnych tajemnic. Widać, że jest podzielona na sekcje, a wcięcia oznaczają szczegóły konfiguracji danego elementu. I tak, konfiguracja interfejsów to sekcja „interfaces”, która zawiera interfejsy Ethernet oznaczone kolejno „eth0″, „eth1″ oraz „eth2″, jak i interfejs loopback. Jak widać, tylko interfejs „eth0″ posiada dodatkowe opcje, w tym wypadku jest to adres IP i maska, odpowiednio 192.168.1.1 oraz 255.255.255.0 (bo właśnie taka maska to inaczej 24 bity).

Adresacja interfejsów

Skoro potrafimy już modyfikować konfigurację, a w pierwszej części w przykładach kasowaliśmy i dodawaliśmy adresy, to dostosujmy konfigurację routera do naszych potrzeb. Przyjmijmy, że chcemy, aby interfejs „eth0″ był interfejsem do sieci Internet (WAN) i uzyskiwał adres automatycznie z DHCP, a na interfejsie „eth1″ chcemy skonfigurować naszą sieć lokalną (LAN) z adresem 192.168.100.1 i maską 255.255.255.0. Poniżej lista komend które musimy wydać, plus krótki komentarz:

• „configure” – aby przejść do trybu konfiguracji,
• „delete interfaces ethernet eth0 address 192.168.1.1/24” – musimy skasować niepotrzebny nam adres,
• „set interfaces ethernet eth0 address dhcp” – konfigurujemy interfejs „eth0” na pobieranie adresu z DHCP,
• „set interfaces ethernet eth1 address 192.168.100.1/24” – nadajemy adres interfejsowi „eth1”,
• „commit” – zatwierdzamy zmiany.

Rezultat zmian możecie zweryfikować znanym już poleceniem „show configuration”, ale w tym wypadku miałoby ono jedną wadę. Mianowicie poznalibyście konfigurację bieżącą interfejsów, ale zamiast adresu interfejsu „eth0”, uzyskalibyście tylko informację, że ma on być pobrany z DHCP. Zmieńmy zatem komendę na „show interfaces”.

Tak jest znacznie lepiej, widzimy listę interfejsów (Interface), ich adresy IP (IP Address) oraz ich stan (S/L), plus ewentualny opis (Description). Czym są te dwie ostatnie kolumny? Pierwsza z nich – S/L, informuje nas o tym, czy interfejs jest administracyjnie włączony (u, z ang. Up) czy wyłączony (A, z ang. Admin Down) oraz jaki jest status linku – aktywny (u) lub nieaktywny (D, z ang. Down). Na czym polega różnica? Link to stan fizyczny – urządzenie sprawdza, czy jest połączone z innym, natomiast stan administracyjny to możliwość celowego włączenia lub wyłączenia interfejsu przez użytkownika. Ostatnie pole pozwala na dodanie do interfejsu krótkiego komentarza, co niewątpliwe ułatwi w przyszłości nam lub innym osobom zrozumienie konfiguracji.

Zostaw sobie wiadomość

Każdy programista wie, jakim koszmarem jest czytanie kodu, nawet własnego, pozbawionego komentarzy. Dla administratora sieci podobny koszmar to brak jakiejkolwiek dokumentacji. Skoro zatem mamy taką możliwość, zostawmy sobie (lub innym) wiadomość, by w przyszłości mieć prostsze zadanie. Komenda, której użyjemy ma postać „set interfaces ethernet ethX description 'komentarz'”, gdzie „x” oznacza oczywiście numer interfejsu. Przy okazji wyłączmy nieużywany interfejs „eth2″ poleceniem „set interfaces ethernet eth2 disable” i porównajmy wynik z wcześniejszym:

Czyż tak nie jest zdecydowanie lepiej? Od razu wiemy, który interfejs jaką rolę pełni, a nawet dodaliśmy informację o operatorze. Nie ma to wielkiego znaczenia, gdy korzystamy z jednego ISP, ale gdybyśmy mieli dwa interfejsy WAN do dwóch dostawców, wtedy na pewno w przyszłości docenimy własną zapobiegliwość. Widzimy również, że stan interfejsu „eth2” został oznaczony literką „A”, czyli wyłączony przez administratora. Tak na marginesie, wyłączanie nieużywanych interfejsów jest dobrą praktyką, zapobiegającą ewentualnym problemom, gdyby ktoś inny lub nawet sami w pośpiechu, roztargnieniu lub z innego powodu, wpięlibyśmy tam jakiś niewłaściwy kabelek.

Interfejs myszki Miki

Ci najbardziej zniecierpliwieni mogą wreszcie odetchnąć z ulgą, uruchomić przeglądarkę i po zaadresowaniu karty sieciowej w podsieci 192.168.100.0/24 i skierowaniu się pod adres https://192.168.100.1 skorzystać z graficznego interfejsu użytkownika. Oczywiście w przypadku powyższej konfiguracji kabel Ethernet wpiąć należy do interfejsu „eth1”. Przy pierwszym skorzystaniu z interfejsu webowego pojawi się komunikat jak niżej z prośbą o zaakceptowanie licencji użytkownika.

Zapominalskim przypominam, że domyślny login i hasło to ubnt.

Routing

Jeśli jednak spodobała się Wam praca z CLI to zapraszam do dalszej lektury. Czego jeszcze potrzebujemy, by móc wreszcie skorzystać z Internetu? Tak, dobrze słyszę, ktoś krzyczy o bramie i/lub routingu? Oczywiście, nasz router musi wiedzieć dokąd kierować ruch. Ale zaraz zaraz, czy on na pewno tego już nie wie? Możemy to sprawdzić wyświetlając tablicę routingu poleceniem „show ip route”.

Ależ wie, dzięki DHCP. Oczywiście nie zawsze jest tak dobrze, że dostawca udostępnia DHCP i czasem musimy adresację i bramę ustawić ręcznie. Adresację już omówiliśmy, zatem pozostaje kwestia bramy. Można ją skonfigurować na dwa sposoby – oba równie dobre i dające ten same efekt.

• „set system gateway-address 172.23.0.1”

lub

• „set protocols static route 0.0.0.0/0 next-hop 172.23.0.1”

Jak wspomniałem efekt, czy to będzie adres uzyskany z DHCP, czy skonfigurowany jedną z tych dwóch komend, będzie taki sam. Po prostu, ta pierwsza komenda jest prostsza do zapamiętania i zrozumienia przez mniej zaawansowanych użytkowników, dla których zagadnienia routingu statycznego i dynamicznego brzmią jak czarna magia i niekoniecznie wiedzą lub chcą wiedzieć co oznacza adres sieci 0.0.0.0/0.

Serwery DNS

Analogicznie do bramy domyślnej wygląda kwestia serwera(ów) DNS lub jeśli ktoś woli serwera(ów) nazw (z ang. name server). Jeśli korzystamy z DHCP, wówczas router pobierze je automatycznie. W przeciwnym wypadku musimy je dodać sami komendą „set system name-server x.x.x.x” gdzie „x.x.x.x” to oczywiście adres IP serwera DNS. Jeśli chcemy dodać więcej niż jeden serwer, kolejne dodajemy ponownie wprowadzając tę komendę. Ja zachęcam do skorzystania z serwerów OpenDNS, których adresy to 208.67.222.222 oraz 208.67.220.220. Wystrzegajcie się natomiast tak popularnych serwerów firmy Google o adresach 8.8.8.8 oraz 8.8.4.4, gdyż jest to jeden ze sposobów szpiegowania Was przez tę firmę i serwowania Wam reklam, między innymi w oparciu o odwiedzane przez Was strony. Przykład konfiguracji serwerów OpenDNS:

NAT

Tak skonfigurowany router będzie już miał dostęp do Internetu, co możemy zweryfikować poleceniem „ping”.

Możecie w tym miejscu spytać, czemu najpierw robię ping dla adresu IP, a potem dla domeny? Z bardzo prostej przyczyny – brak odpowiedzi na ping na znany adres IP, o którym wiemy, że nie filtruje zapytań ICMP pozwala sprawdzić czy mamy poprawną adresację i czy wszystko działa, natomiast ping nazwy pozwala sprawdzić, czy poprawna jest konfiguracja serwerów nazw i otrzymujemy od nich odpowiedź. Jeśli jednak ten sam manewr wykonalibyście z komputera, okaże się, że test zakończy się niepowodzeniem. Tak, tak, została jeszcze jedna rzecz do skonfigurowania czyli NAT lub jak wolą inni PAT, a miłośnicy Linuksa zakrzykną maskarada (z ang. masquerade), bo przecież w Linuksie wszystko musi być inaczej ;P Wydajemy więc komendy:

• „set service nat rule 5000 outbound-interface eth0”,
• „set service nat rule 5000 protocol all”,
• „set service nat rule 5000 type masquerade”.

Bardziej zaawansowaną konfigurację mechanizmów NAT jeszcze omówimy, więc w skrócie, powyższe komendy tworzą regułę numer 5000. Nie jest on przypadkowy, EdgeOS narzuca zakresy numeracji w zależności od rodzaju NATu i w przypadku nie zastosowania się do wytycznych, po prostu dostaniemy komunikat błędu. Reguła, którą utworzyliśmy mówi, aby stosować maskaradę (dynamiczny NAT adresów źródłowych), dla wszystkich protokołów, dla pakietów wychodzących interfejsem „eth0”.

Sukces, udało się nam skonfigurować router z systemem EgdeOS do obsługi Internetu Ale zanim zaczniecie świętować. profilaktycznie zmieńcie użytkownika i hasło:

• „set system login user testhub authentication plaintext-password 'haslo'”.

Konieczne jest też usunięcie użytkownika „ubnt”, ale nie uda się wam tego zrobić bez wylogowania i zalogowania jako nowy, przed chwilą dodany użytkownik „testhub”, gdyż otrzymacie komunikat błędu „Attempting to delete current user: ubnt”. Zatem wydajemy polecenie „exit” w trybie operacyjnym, co spowoduje wylogowanie i logujemy się już jako nowy użytkownik.

Przypominam o zapisaniu konfiguracji! I jeszcze ważna uwaga. Gdybyście po dodaniu użytkownika zajrzeli do konfiguracji to odkryjecie, że hasło, które przed chwilą podaliście jawnym tekstem, w konfiguracji jest zaszyfrowane. Również w pliku z kopią zapasową jest ono nie do odczytania (dla dociekliwych jego fragment wygląda tak: $6$Xzz6titfBc$SVwMWbuZAk3oBZPFbZKWjKSP87gCjsQ….), zatem warto je zapamiętać, bo w przypadku jego utraty konieczny będzie restart urządzenia do ustawień fabrycznych, co oznacza pożegnanie się z konfiguracją, często długo dopieszczaną i dopracowywaną.

Podsumowanie

Nie, tym razem nie będę przypominał wszystkich komend jeszcze raz. Za to zachęcam do przećwiczenia ich celem utrwalenia, zabawy ze zmianą adresacji i odkrywania dodatkowych opcji, które podpowie wam znak zapytania. Na zachętę zdradzę komendę „show configuration all”. Napiszcie w komentarzach swoimi słowami, czym różni się jej wynik od samego „show configuration”.

Artykuł Podstawy pracy z interfejsem linii komend (CLI) systemu EdgeOS – część 2 pochodzi z serwisu TestHub.pl.

System operacyjny routerów serii EdgeMax firmy Ubiquiti Networks, nosi nazwę EdgeOS. Bazuje on na Debian GNU Linux, przy czym posiada własny command line do konfigurowania wszystkich usług, dzięki czemu nie musimy sięgać do plików konfiguracyjnych każdej usługi systemu Linux z osobna oraz interfejsu graficznego (GUI). Swoimi korzeniami EdgeOS sięga projektu VyattaOS w wersji 6.3 community edition (system dostępny był w niekomercyjnej edycji community oraz jako produkt komercyjny). Świadomie i celowo unikam określenia EdgeOS jako fork’a systemu VyattaOS z dwóch powodów. W świecie free and open source software przyjmuje się, że fork to projekt rozwijany równolegle i okresowo aktualizowany względem swojego pierwotnego źródła. I tak forkiem Ubuntu jest Kubuntu, przy czym oba projekty są rozwijane równolegle, sięgają do tych samych repozytoriów, a kolejne wersje wydawane są w podobnym cyklu. Taka zależność nie zachodzi pomiędzy EdgeOS a VyattaOS, ponieważ ten drugi system nie jest już rozwijany (powstał co prawda projekt VyOS, ale to już temat na inną okazję), w konsekwencji zakupu firmy Vyatta przez Brocade w 2012 roku. Ostatnia wersja VyattaOS 6.6 wydana została w maju 2013 roku. Zatem właściwie od początku, bo EdgeOS w wersji 1.0.2 wydany został 7 listopada 2012 roku, rozwijany jest jako osobny projekt.

Tryb operacyjny i tryb konfiguracji

Po zalogowaniu do systemu (poprzez port konsoli, z użyciem protokołu SSH lub z poziomu okna terminala w GUI), lądujemy w trybie nazwanym przez producenta „operacyjnym” (z ang. operational mode), który rozpoznajemy po znaku zgłoszenia (z ang. prompt) „admin@CERBER:~$”, zakończonym symbolem „$”. Tak przy okazji, prompt składa się z nazwy użytkownika oraz nazwy hosta, w tym wypadku jest to użytkownik „admin”, na hoście o nazwie „CERBER”. Listę wszystkich dostępnych w tym trybie komend uzyskamy przez wprowadzenie w terminalu znaku zapytania „?”,  co poskutkuje wyświetleniem samych nazw komend, a jeśli ponownie wprowadzimy znak zapytania, efektem będzie lista w postaci komend, z ich krótkim opisem. Zatem zobaczmy, jak to działa w praktyce (w terminalu nie widać znaków zapytania wprowadzonych z klawiatury).

Więcej o poszczególnych komendach opowiem w kolejnych częściach cyklu, natomiast na tym etapie poznawania CLI najważniejsza z nich to „configure”, która pozwala przejść do trybu konfiguracji (z ang. configuration mode). O zmianie trybu informuje zmieniony znak zgłoszenia na „#”. Poniższy obrazek prezentuje, jak taka operacja wygląda w praktyce i od razu skorzystajmy z podpowiedzi, którą już wiecie jak uzyskać.

Z trybu konfiguracji do trybu operacyjnego wracamy komendą „exit”.

Hello world!

Nie, programować nie będziemy, ale spróbujmy coś wreszcie skonfigurować. Kluczową komendą, która pozwala ustawić wartość parametru lub stworzyć nowy element to „set”.  Jeśli zatem chcielibyśmy zmienić nazwę hosta, powiedzmy na „testhub”, to w trybie konfiguracji trzeba użyć komendy „set system host-name testhub”. Tak, wiem, poza set pojawiło się jeszcze kilka opcji, których nie znacie, ale wszystko z czasem się wyjaśni. Co bardzo ważne, samo wydanie tego polecenia nie spowoduje absolutnie żadnych zmian. Osoby przyzwyczajone do pracy z CLI Cisco, mogą w tym momencie być nieco zaskoczone, zaś te zaznajomione, np. z CLI Junipera, poczują się prawie jak w domu. Otóż zmiany (może być ich wiele) musimy zatwierdzić komendą „commit”. Rozwiązanie to ma swoje zalety – wybiegnę tu trochę do przodu, ale chcę, żebyście zrozumieli istotę tego rozwiązania. Powiedzmy, że potrzebujecie zmienić adres IP interfejsu WAN pracując zdalnie. Kroki, jakie w tym celu trzeba uczynić, to usunąć stary adres i dodać nowy. Czyli w tym wypadku, byłyby to kolejno komendy „delete interfaces ethernet eth0 address stary_adres_IP” i zaraz po niej „set interfaces ethernet eth0 address nowy_adres_IP”. Już macie pomysł, czemu bez „commit” mielibyśmy problem? Gdyby pierwsza komenda została wykonana od razu po wprowadzeniu, interfejs straciłby adres IP i odcięlibyśmy się od routera, zanim zdążylibyśmy wprowadzić nowy adres IP. Dzięki temu, że zmiany są wykonywane dopiero po poleceniu „commit”, możemy wprowadzić wszystkie zaplanowane zmiany i dopiero na koniec niejako nakazać ich wykonanie. W praktyce wyglądałoby to tak:

Uważni czytelnicy, zapewne zauważyli jeszcze jedną komendę, mianowicie „save”. Popularnie stosowane urządzenia domowe, czasem pogardliwie nazywane „mydelniczkami” (zapewne z racji kształtu i plastikowej obudowy), mają tę cechę, moim zdaniem brzydką, że od razu wszystkie wprowadzone zmiany zapisują. Czemu brzydką? Bo jak coś popsujemy w konfiguracji, to często zostaje tylko reset do ustawień fabrycznych. Dlatego te bardziej zaawansowane urządzenia, posiadają zazwyczaj niezależnie dwie konfiguracje – bieżącą, czyli tę, którą modyfikujemy i startową, czyli tą, z którą urządzenie się uruchomiło. Aby zmiany dokonane w konfiguracji bieżącej utrwalić w konfiguracji startowej, należy je zapisać i temu jak się zapewne już domyśliliście, służy komenda „save”. Jej odpowiednikiem, np. w CLI Cisco jest „copy running-config startup-config”.

Tylko bez paniki ;(

Jak się ratować w sytuacji, gdy zdarzy się wam błąd? Jedną z opcji poznaliście – przed zapisaniem konfiguracji zawsze można ratować się restartem urządzenia. Jest to jednak rozwiązanie nieeleganckie i nieefektywne (tracicie w ten sposób owoc często długich minut spędzonych na konfigurowaniu urządzenia), a w przypadku routerów z EdgeOS, nie wolno tego robić poprzez zwyczajne wyłączenie zasilania, gdyż bez poprawnego zamknięcia systemu operacyjnego można uszkodzić system plików.

Rozważmy zatem kilka przypadkowych problemów. W najprostszym, niech to będzie literówka w poleceniu, a zatem trzymając się wcześniejszego przykładu, zamiast nazwy hosta testhub wprowadziliśmy polecenie „set system host-name tetshub”. Rozwiązanie jest bardzo proste i zamiast zatwierdzać zmiany, po prostu je odrzucamy komendą „discard”. Tu od razu uwaga – samo wyjście z trybu konfiguracji poleceniem „exit” nie wystarczy – system zasygnalizuje błąd „Cannot exit: configuration modified”, mówiący o tym, że dokonano zmiany konfiguracji. Można natomiast połączyć te polecenia w jedno i wydać komendę „exit discard”.

Jeśli zdarzy się, że błąd spostrzeżemy już po jego zatwierdzeniu, pomocna jest komenda „delete”, która pojawiła się przy okazji dygresji o zmianie adresacji, a służy do usuwania wartości parametru lub elementu. Zróbmy zatem celowo błąd, a potem go usuńmy.

Co się wydarzyło? Zachowałem się jak początkujący administrator i popełniwszy błąd w adresie IP w komendzie „set interfaces ethernet eth1 address 10.10.10.1/24″, postanowiłem go poprawić, wydając polecenie po raz kolejny, ale tym razem z dobrym adresem „set interfaces ethernet eth1 address 20.10.10.1/24″. I tu tkwi pułapka na początkujących adeptów administracji sieciami – otóż w przeciwieństwie do wspomnianych „mydelniczek”, nie jest niczym niezwykłym dla takiego routera posiadanie dwóch adresów na jednym interfejsie, co pokazuje powyżej komenda „show interfaces ethernet eth1″. Rozwiązaniem tego problemu jest właśnie komenda  „delete” i w tym przypadku miałaby ona postać „delete interfaces ethernet eth1 address 10.10.10.1/24″. Przy okazji widać, że router przypomina o konieczności zapisania zmian, jeśli tego nie uczyniliśmy, a skorzystamy z komendy „exit”. 

Uzupełnianie komend

Podczas pracy z CLI, drugim użytecznym klawiszem na klawiaturze, poza już poznanym znakiem zapytania jest Tabulator, na części klawiatur opisany jako Tab. Działa on podobnie jak u innych producentów i pozwala szybko uzupełniać komendy. Na przykład, jeśli napiszemy tylko litery „sh” i wciśniemy klawisz Tab, system podpowie nam, że tak rozpoczynają się dwie komendy „show”  oraz „shutdown”, natomiast ten sam Tab naciśnięty po literach „shu”, już bez dalszych podpowiedzi uzupełni się do „shutdown”.

Podsumowanie

Powinniście już umieć poruszać się po trybach operacyjnym i konfiguracji, do którego przechodzimy komendą „configure”, a wychodzimy z niego poleceniem „exit”. Zmiany wartości parametru lub dodanie elementu realizuje „set”, natomiast skutek odwrotny uzyskamy, sięgając po „delete”. Zmiany należy zatwierdzić poleceniem „commit” lub odrzucić komendą „discard”. Aby utrwalić zmiany w konfiguracji bieżącej należy je zapisać komendą „save” w konfiguracji startowej. W każdej chwili możecie też skorzystać z pomocnych klawiszy „?” oraz „Tab”.

Artykuł Podstawy pracy z interfejsem linii komend (CLI) systemu EdgeOS – część 1 pochodzi z serwisu TestHub.pl.

Firma Ubiquiti Networks wprowadziła do oferty dwa nowe routery serii EdgeMAX o nazwach  EdgeRouter 4 (ER-4) oraz EdgeRouter 6 (ER-6). Cyfra w nazwie odpowiada ilości portów Ethernet w każdym modelu. Routery posiadają jedno gniazdo w standardzie SFP na moduł miniGBIC z myślą o podłączeniu do infrastruktury operatora łączem światłowodowym oraz odpowiednio 3 (ER-4) lub 5 (ER-6) portów 10/100/1000 Mbps w standardzie RJ45. Wyposażone są w 4-rdzeniowy procesor MIPS 64 taktowany zegarem 1 GHz, pamięć RAM DDR3 o pojemności 1 GB oraz pamięć FLASH w standardzie eMMC o pojemności 4 GB. Widoczny na zdjęciach port USB nie jest obsługiwany w obecnych wersjach oprogramowania. Całość zamknięta jest w pasywnie chłodzonej, zgrabnej metalowej obudowie o kompaktowych wymiarach 229 x 136.5 x 31.1 mm, jednakże dla klientów chcących zainstalować go w standardowej szafie RACK 19″ ma być dostępny opcjonalny zestaw montażowy oznaczony symbolem  ER-RMKIT. Producent określa przepustowość urządzeń na poziomie 3,4 miliona pakietów na sekundę (pps) dla pakietów 64 bajty. Model ER-4 pojawił się już w cennikach polskich dystrybutorów, natomiast ER-6 powinien być dostępny do końca roku.

Artykuł EdgeRouter 4 & EdgeRouter 6. Nowe routery od Ubiquiti Networks (UBNT) pochodzi z serwisu TestHub.pl.

W sumie to zaczynając od historii firewalli złamałem chronologię powstawania rozwiązań, które przyczyniły się do stworzenia i rozwoju Internetu, bo pierwszym urządzeniem, pomijając oczywiście same komputery, był router. I nie, nie popełniam błędu używając liczby pojedynczej, bo wszystko zaczęło się od jednego, konkretnego urządzenia, uruchomionego w 1969 roku na Uniwersytecie Kalifornijskim w Los Angeles. A oto jak do tego doszło.

Jeszcze taka mała dygresja. Planowałem ten artykuł już jakiś czas temu, ale tak mi schodziło i pewnie jeszcze jakiś czas bym się z tym ociągał, gdyby nie lektura „Innowatorów” Waltera Isaacsona. Rozdział 7 podziałał jako impuls do działania, tym bardziej, że książka dostarczyła prawie gotowy materiał. Więc kto czytał, zapewne zauważy obszerne zapożyczenia, a kto jeszcze nie czytał, może poczuje się zachęcony, bo naprawdę warto sięgnąć po tę pozycję. I chociaż książka ma ponad 700 stron, a rozdział 7 blisko 70, to czyta się ją naprawdę jak dobrą powieść.

Potrzeba (a może wygoda) matką wynalazku

Jak większość wynalazków, tak i router zrodził się z potrzeby rozwiązania konkretnego problemu. Problemem w tym wypadku był egoizm naukowców i potrzeba oszczędności środków, wydawanych na bardzo drogi, a nie zawsze najlepiej wykorzystywany sprzęt komputerowy (skąd my to znamy!). Każdy z uniwersytetów i ośrodków badawczych związanych kontraktami z agencją ARPA (Advanced Research Projects Agency), chciał mieć najnowszy sprzęt o największych możliwościach, oczywiście na własny i wyłączny użytek. Prowadziło to do mało racjonalnego wydatkowania zawsze zbyt szczupłych środków, jakie były dostępne na badania i duplikowania sprzętu. Nieekonomiczność tego podejścia zauważył Robert William Taylor (Isaacson w swojej książce nazywa go Bobem, choć nie było to jego imię a nazywali go tak znajomi), który objął kierownictwo IPTO (Information Processing Techniques Office, czyli Biuro Technik Przetwarzania Informacji, było jednym z departamentów ARPA) w 1966 roku. Taylor uświadomił sobie, że warto by było stworzyć między ośrodkami akademickimi elektroniczne łącza, dzięki którym urządzenia mogłyby dzielić zadania i czas pracy, a ludzie w łatwy sposób wymieniać informacje, bez konieczności odbywania czasochłonnych podróży. Niewykluczone też, że impulsem do działania były trzy terminale – każdy z innym zestawem poleceń – podłączone do różnych centrów komputerowych, sfinansowanych przez agencję ARPA, jakie stały w biurze Taylora w Pentagonie. Jak rzekomo miał powiedzieć sam szef IPTO, konieczność używania tych trzech terminali „doprowadziła do objawienia”. Sieć sfinansowana i narzucona jako obowiązkowa przez ARPA, pozwoliłaby ośrodkom badawczym dzielić się zasobami obliczeniowymi i podejmować współpracę przy różnych projektach. No a skutkiem ubocznym byłoby pozbycie się przez Taylora dwóch zbędnych terminali stojących w jego biurze

Właściwy człowiek na właściwym miejscu

Taylor zlecił prace nad rozwiązaniem powyższego problemu Larryemu Robertsowi. Skądinąd po latach panowie serdecznie się nie lubili i każdy z nich zawzięcie umniejszał dokonania drugiego. Ale to było później, natomiast w ciągu czterech lat wspólnej pracy w ARPA, Taylor i Roberts dobrze się uzupełniali. Kluczowym momentem było zapewne spotkanie w kwietniu 1967 roku na Uniwersytecie Michigan. To na nim Roberts przedstawił koncepcję połączenia ośrodków naukowych dzierżawionymi liniami telefonicznymi. Jak się nietrudno domyślić „uniwersytety z zasady nie chciały się z nikim dzielić swoimi komputerami – powiedział Roberts – zależało im na tym, by kupić takie urządzenia, a następnie ukryć”. Przeciwnicy tego pomysłu utrzymywali, że ich komputery i tak są wykorzystywane do granic możliwości, a konieczność zmagania się z ruchem sieciowym dodatkowo ujmie im mocy obliczeniowej. ARPA miała oczywiście istotny argument – wszyscy uczestnicy spotkania korzystali z dotacji ARPA – zdecydowano zatem, że warunkiem otrzymania kolejnych środków na zakup nowych komputerów miało być podłączenie do sieci posiadanych już urządzeń.

Jeden, by wszystkimi rządzić, Jeden, by wszystkie odnaleźć

Argument siły zawsze jest objawem słabości, świadomi byli tego Taylor i Roberts. Na szczęście w gronie uczestników spotkania był Wes Clark, który stworzył w Lincoln Laboratory komputer osobisty nazwany LINC. Zaproponował on by ARPA nie forsowała na siłę rozwiązania, które wymuszałoby kierowanie przepływem danych w sieci za pomocą komputerów badawczych, pracujących w poszczególnych ośrodkach, leczy by zaprojektowała i przekazała każdej z tych instytucji ustandaryzowany mikrokomputer, który realizowałby takowe zadanie. Zalety takiego podejścia to minimalizowanie obciążenia jednostki centralnej działającej w danym ośrodku, możliwość opracowania jednolitego standardu sieci przez ARPA oraz realne rozproszenie procesu przekazywania danych. Pomysł znalazł uznanie tak Taylora jak i Robertsa, a standaryzowany mikrokomputer zasugerowany przez Clarka wkrótce ochrzczono mianem Interface Message Processor (z ang. Procesor Wiadomości Interfejsu) w skrócie IMP. Później nazwano je po prostu routerami.

ARPA Net

Zmodyfikowany plan sieci Roberts przedstawił w październiku 1967 roku na konferencji w Gatlinburgu w stanie Tennessee. Wówczas też pojawiła się nazwa ARPA Net, z czasem zmieniona na ARPANET. Nierozstrzygnięta pozostawała kwestia realizacji połączeń między punktami sieci. Wówczas głos zabrał młody inżynier z Wielkiej Brytanii, Roger Scantlebury, który opisał badania swojego przełożonego Danalda Daviesa z National Physical Laboratory nad metodą podziału komunikatów na niewielkie jednostki, nazwane „pakietami”. Scantlebury nie omieszkał przyznać, że podobna koncepcja była rozwijana niezależnie przez Paula Barana działającego w RAND (amerykański think tank i organizacja badawcza non-profit, założona w 1948 roku).

Komutacja pakietów i… polski akcent

Osobą, która jako pierwsza wpadła na pomysł zbudowania sieci wykorzystującej komutację pakietów, był inżynier Paul Baran. Gdy miał dwa lata, jego rodzina wyemigrowała z Polski i osiedliła się w Filadelfii. Podobno kluczowym momentem, który zaważył na jego dalszej karierze, była próbna detonacja bomby wodorowej, dokonana przez ZSRR w 1955 roku. Uwaga Barana skupiła się na kwestii zbudowania wojskowego systemu komunikacyjnego zdolnego przetrwać atak wroga. Stworzył on około roku 1960 dwie kluczowe koncepcje. Pierwsza dotyczyła decentralizacji sieci – należało zrezygnować z tworzenia centralnego węzła lub nawet węzłów, które kontrolowałyby przesył danych. Gdyby wróg zdołał zniszczyć kilka takich centrów, mógłby unieruchomić cały system. Sterowanie procesem przesyłania danych powinno być całkowicie rozproszone, a każdy węzeł powinien mieć jednakowe uprawnienia do przełączania i przekierowywania przepływu danych. Ta koncepcja stała się fundamentem Internetu. Druga koncepcja dotyczyła rozbijania danych na niewielkie fragmenty o standardowych rozmiarach. Wiadomość miała być dzielona na wiele takich segmentów, przesyłanych rozmaitymi ścieżkami przez węzły sieci, by po dotarciu do celu znów stworzyć spójną całość. Zainteresowanych problemami jakie Baran napotkał, usiłując przekonać do swoich pomysłów czy to Siły Powietrzne USA czy AT&T odsyłam do książki „Innowatorzy”.

Koncepcje Barana przybrały ostatecznie postać jedenastu tomów szczegółowych analiz technicznych zatytułowanych „On Distributed Communications” i ukończonych w 1964 roku. Nie wiadomo jaki byłby ich los, gdyby nie konferencja w Gatlinburgu, po powrocie z której Roberts odkopał raporty Barana. Roberts dotarł również do referowanych na konferencji prac Donalda Daviesa, który z kolei skupiał się na zagadnieniu dzielenia czasu komputerów i używania linii telefonicznych do przesyłania danych. To również Davies zaproponował stare angielskie słowo packet, jako nazwę takiej porcji danych. Tak jak Baran w USA, tak Davies w swoim kraju napotkał opór materii. Obaj znaleźli w końcu sprzymierzeńca w osobie Larryego Robertsa, który poparł ich pomysły i zaakceptował nazwę „pakiet”.

Od teorii do praktyki

Latem, 1968 roku Larry Roberts zaprosił do przetargu 140 firm potencjalnie zainteresowanych wytwarzaniem mikrokomputerów mających pełnić funkcję routerów, czyli jednostek IMP w sieci ARPANET. Urządzenia miały wykorzystywać koncepcje komutacji pakietów Paula Barana i Donalda Daviesa, sugestie Wesa Clarka dotyczące standaryzacji urządzeń, spostrzeżenia J.C.R.Licklidera, Lesa Earnesta, Leonarda Kleinrocka (dość kontrowersyjna postać, która w pewnym momencie zaczęła przypisywać wszystkie zasługi wyłącznie sobie), a także wkład wielu innych naukowców. Na przesłanie ofert zdecydowało się jedynie kilkanaście przedsiębiorstw, ale finalnie wybór ważył się między Raytheonem a BBN (Bolt, Beranek and Newman). Po latach Taylor wspominał „Raytheon przedstawił dobrą propozycję, która nie ustępowała ofercie BBN. Na dłuższą metę jedyna różnica, która zaważyła na mojej ostatecznej decyzji, polegała na tym, że BBN miał bardziej zdyscyplinowany zespół, który moim zdaniem zapewniał większą efektywność”. Jako ciekawostkę dodam, że w 2009 roku Raytheon kupił BBN, natomiast IBM zrezygnował z udziału w przetargu, oceniając pomysł jako nierealny.

Wynik przetargu i wygrana BBN zostały ogłoszone tuż przed Bożym Narodzeniem. Głównymi inżynierami odpowiedzialnymi za realizację zlecenia byli Frank Heart i Robert Kahn, obydwaj w przeszłości związani z MIT. Pomogli oni rozwinąć pomysły ARPA i założyli, że gdy jakiś pakiet będzie przesyłany z jednego IMP do drugiego, router wysyłający informacje powinien przechowywać je, aż do momentu, w którym otrzyma potwierdzenie dostarczenia danych od routera odbierającego, a gdyby taki komunikat nie nadszedł w odpowiednio krótkim czasie, dane powinny zostać wysłane jeszcze raz.

Request for Comments (RFC)

Pierwszymi węzłami sieci ARPANET miały zostać UCLA (Uniwersytet Kalifornijski, kampus Los Angeles), Stanford Research Institute (SRI), Uniwersytet Utah oraz Uniwersytet Kalifornijski (z siedzibą w Oakland w stanie Kalifornia). Każdy z tych ośrodków otrzymał zadanie polegające na znalezieniu sposobu podłączenia ich głównych komputerów do ustandaryzowanych IMP. Funkcję koordynatora objął Stephen Crocker, doktorant z UCLA, który dzięki uprzejmości i bezpretensjonalności miał naturalny dar do godzenia towarzystwa i zaprowadzania powszechnej zgody. Przypadł mu w udziale obowiązek sporządzania sprawozdań z ustaleń grupy nazwanej Network Working Group. Jak sam wspomina „Uświadomiłem sobie, że już samo spisanie tego, o czym dyskutowaliśmy, mogło być postrzegane jako próba uzurpowania sobie władzy – to zaś doprowadziłoby do pojawienia się tutaj kogoś, kto przywróciłby nas do pionu (…) Usiłując podkreślić nieformalną naturę tych dokumentów, wpadłem na naiwny pomysł nazwania każdego z nich Request of Comment – RFC (z ang. prośba o komentarze) – niezależnie od tego, czy tekst faktycznie miał charakter takiego wniosku, czy nie”. Pierwszy dokument RFC został rozesłany pocztą tradycyjną, 7 kwietnia 1969 roku.

Do końca sierpnia 1969 roku w wyniku prac grupy, opisanych w kolejnych RFC, opracowano zestaw standardów komunikacji między komputerami działającymi na uczelniach a jednostkami IMP. A już 30 września 1969 roku, pierwszy taki router dotarł na UCLA, gdzie został powitany… szampanem. Pewnym zaskoczeniem były rozmiary rzekomego mikrokomputera, który w istocie przypominał lodówkę.

Firma BBN spisała się doskonale, mieszcząc się zarówno w terminie jak i budżecie.

Sieć!

Miesiąc później drugi IMP dotarł do SRI w kampusie Uniwersytetu Stanforda i można było uruchomić ARPANET, co nastąpiło 29 października. Jak na tak przełomowe wydarzenie, miało ono nad wyraz prozaiczną oprawę i przebieg. A jeśli chcecie o tym przeczytać więcej, odsyłam do lektury „Innowatorów”.

W roku 1969 wydarzyły się trzy przełomowe rzeczy – NASA wysłała człowieka na księżyc, inżynierom z Doliny Krzemowej udało się stworzyć mikroprocesor, a ARPA zbudowała sieć, która dała podwaliny pod Internet. I tylko pierwsze z tych wydarzeń wówczas przykuło powszechną uwagę.

Artykuł Ten pierwszy ROUTER pochodzi z serwisu TestHub.pl.

Linksys WRT1900ACS – cena dostępna pod adresem: http://bit.ly/2jCd9Os

Artykuł Router Linksys WRT1900ACS – recenzja pochodzi z serwisu TestHub.pl.