Test TP‑Link, czyli zestaw biznesowy do robienia internetów: część 2 — pierwsze testy

Rozpocznę od testu switcha. TP‑Link T1500-10MPS został zainstalowany na biurku, a także skonfigurowany.

Jak przebiegła konfiguracja?

Możemy grzebać przez WWW, jak i przez SSH. No i Telnet.

Przy pierwszym uruchomieniu jesteśmy skazani na WWW. No i kulawy telnet. Wiem, że dla wielu osób będzie to zaskoczeniem, ale nie lubię zarządzania sprzętem sieciowym z poziomu GUI. Ok, śmierdzi to trochę memem pt. „ja tam wolę mieć kontrolę nad autem”, ale to dokładnie tak wygląda.

Nie wiem, czy to kwestia tego, że skonfigurowanie sprzętu z konsoli jest szybsze, czy to tylko wprawa, w każdym razie wolę CLI.

Wita nas interfejs znany z innych urządzeń od TP‑Linka. Jest prosty, przejrzysty (lepszy niż w Cisco!), bardzo płynnie działa, wszystkie opcje są względnie logicznie poukładane.

Dlaczego względnie? Bo nie zrozumcie mnie źle – w konsoli czuje się lepiej, wiem gdzie szukać poszczególnych opcji, a mój romans z GUI kończy się po włączeniu SSH.

Niemniej trafiłem kiedyś na (T1600 w wersji 52 portowej) odporną na SSH sztukę i konfigurowałem dziada przez WWW i właściwie wszystko udało mi się prawidłowo poskładać. Więc da się, ręce nie odpadają po takim zabiegu, a do tego jak na złość, rzeczony dziad działa radośnie nadal. Od roku.

Jak skonfigurowałem T1500-10MPS?

Port Gi1/0/1 oraz Gi1/0/8 mają nietagowany vlan 1 (default) oraz tagowany vlan 200. To będzie mi potrzebne do testów. Docelowo będą inne vlany, w tym jakiś z TV, co później przetestuję. Te porty oznaczyłem jako zaufane w DHCP Snooping.

Porty Gi1/0/2-7 zostały skonfigurowane jako nietagowany vlan 1 i na razie (do czasu zabawy z innymi vlanami) takie pozostaną. Zostały oznaczone jako niezaufane w DHCP Snooping. Nikt nie zaleje nas z tych portów swoim serwerem DHCP, switch nieodpowiednie zapytania po prostu wywali.

Reszta konfiguracji to na razie nic nie znaczące vlany, które będą mi potrzebne w dalszej części testu.

Na tym etapie widzę już pewne podobieństwa i różnice względem Cisco CLI, które dla wielu jest wzorem konsoli w urządzeniach sieciowych.

W CLI możemy posługiwać się pytajnikiem „?”, aby TP‑Link nam podpowiedział, co możemy wpisać w danym momencie. Auto uzupełnianie tabulatorem także zostało zaimplementowane. Bajecznie ułatwia to konfigurację. Same polecenia są niemal identyczne na Cisco CLI, jak i TP‑Link CLI.

Przykład?

Załóżmy, że chcemy sprawdzić do jakich VLANów jest przypisany dany port. W Cisco wygląda to tak:

na przykład:

Co przekłada się na wynik:

na TP‑Linku jest odrobinę inaczej:

Na przykład:

Składnia jest podobna, nazewnictwo portów inne (to nie problem), ale wyniki są inne. Cisco ma o wiele bardziej szczegółowe wyniki, TP‑Link wypada tutaj ubogo.

Podobne różnice są w dodawaniu portu do VLAN.

Różnic jest oczywiście więcej, niektóre wynikają z nomenklatury zastosowanej u obydwu producentów, niektóre wynikają z różnic w zastosowanych technologiach. Nie jest to wada, ale silnie wskazuje na fakt, że TP‑Link nie ma skrajnego parcia na cisco-like-CLI, jak niektórzy inni producenci. Taki Allied Telesis to kopia niemal doskonała Cisco, różniąca się jedynie pewnymi niuansami. Jednocześnie nie jest to taki egzotyk jak Mikrotik (z punktu widzenia ciscoluba).

Przetestujmy zatem wspomniany wyżej DHCP Snooping.

Na porty Gi1/0/2-7 wrzuciłem to zabezpieczenie, w teorii każde zapytanie pochodzące z niezaufanego portu powinno być wywalone przez swticha. Sprawdźmy to.

Sytuacja prawidłowa

Serwer DHCP (router) jest na zaufanym porcie (Gi1/0/8), klient na porcie niezaufanym (Gi1/0/7).

Na komputerze mam dwa interfejsy sieciowe: wlan0 (sieć WiFi, podłączona do routera bezprzewodowo, sieć 192.168.1.0/24) oraz eth0 (sieć LAN, podłączona do switcha wg powyższego opisu, sieć 192.168.1.0/24). Zanim zaczniemy konfigurować, wywalę wpis z tablicy routingu w systemie, aby cały ruch kierował przez wlan0.

Na eth0 obchodzą nas tylko ramki odpowiedzialne za DHCP, więc nie powinno nam tam nic więcej brykać.

Rzućmy okiem, jak to wygląda w Wiresharku:

Trudno ukryć tutaj książkową wymianę informacji w ramach DHCP.

Konfiguracja przyznana:

Popsujmy to teraz

Podłączmy router (serwer DHCP) pod inny port, Gi1/0/3 na przykład. To jest niezaufany port. Co się stanie teraz?

Ponownie kontroluję tablicę routingu, zrzucam dhclientem konfigurację i próbujemy.

Nie działa, więc działa

Nie otrzymałem konfiguracji z serwera DHCP podłączonego do niezaufanego portu. To prawidłowe zachowanie. Nie zauważyłem w Wiresharku, aby jakieś pakiety z serwera DHCP przeciekały. Not bad.

A może by tak podsłuchać inny port?

W diagnostyce sieci bardzo przydatnym narzędziem jest mirroring portów. Polega to na tym, że pakiety wysyłane z hosta A do hosta B (i odwrotnie) są wysyłane także do hosta C

Host C nie prowadzi w tym czasie transmisji (a przynajmniej nie powinien), a jedynie nasłuchuje ruch. Uruchomię więc Port Monitor (tak się to nazywa na tym urządzeniu) i sprawdzę, czy działa. Szybki podgląd na aktywne sesje Port Monitora:

Widzimy, że sesja jest aktywna. Rzut okiem w Wiresharka:

Podsłuchałem port, z którego host chciał otrzymać adres IP w ramach DHCP w momencie, gdy serwer DHCP był w niezaufanym porcie. Odfiltrowałem jedynie interesujące mnie pakiety. To potężne narzędzie, bo pozwala na na prawdę wiele w trakcie diagnostyki sieciowej.

Plany na później

Dalsze testy funkcjonalności dodam w późniejszych wpisach. Mój chytry plan zakłada przetestowanie TP‑Linka T1500-10MPS trochę pod kątem ISP. Już na tym etapie widzę, że do domu lub małego biura ma solidne predyspozycje. Do biura przyda się jeszcze Port Protection (bądź jego TP‑Linkowy odpowiednik), ale sprawdzę tę funkcjonalność w następnym odcinku. Nie jestem jednak póki co pewien, czy wdrożyłbym go na węzeł w sieci u ISP. Wiem, że jego wydajność przełączania jest teoretycznie wystarczająca, aby obsłużyć ruch gigabitowy na każdym porcie, ale to jednak nie wszystko, co do szczęścia się nam przyda.

Do zobaczenia!