MikroTik

Przekierowanie zapytań DNS do lokalnego resolvera

Napisane przez Igor Brzeżek on 8 marca 2025
Napisane w: Bezpieczeństwo, MikroTik, Sieci.

Zapytania DNS
Zapytania ruchu DNS standardowo wysyłane są protokołem DNS na port 53. Jeśli klient ma ustawiony adres serwera publicznego np. Cloudflare 1.1.1.1 to ruch ten „przechodzi” przez nasz routrer (ja wszelki inny do Internetu). Zatem mamy możliwość przechwycenia takiego ruchu i skierowania go do lokalnego resolvera DNS celem zaszyfrowania połączeń do publicznych serwerów DNS. Rozwiązań jest wiele, tutaj opiszemy sposób RouterOS. Inne rozwiązania to PiHole, AdGuard, Technitium. Są to aplikacje (serwery) buforujące i szyfrujące DNS oraz blokujące niebezpieczne treści, reklamy itp.

Poniżej widok konfiguracji klienta DNS systemu Linux. Zazwyczaj mamy wpis jednego lub częściej dwóch adresów serwerów DNS w pliku /etc/resolv.conf

Standardowo zapytanie (zapewne nieszyfrowane) wygląda tak:

W tym przypadku Linux wysyła zapytania bezpośrednio do Cloudflare a jeśli nie otrzyma odpowiedzi to jeszcze spróbuje zapytać Google. Bezpośrednio w sensie DNS ale oczywiście taki ruch przejdzie przez nasz router.

Jeśli popatrzymy na połączenia to zobaczymy, że host 192.168.0.2 (Linux) łączy się z hostem 1.1.1.1 po UDP na port 53 czyli typowy ruch zapytań DNS. Nie jest on szyfrowany. Router teraz pracuje tylko jako router i żądnych usług DNS nie świadczy więc na razie ma się nijak do kwestii DNS a tym bardzie bezpieczeństwa tego ruchu.

Szyfrowanie ruchu DNS z routera
Jeśli na routerze skonfigurujemy szyfrowany ruch DNS do publicznych serwerów, włączymy lokalny serwer DNS buforujący i skonfigurujemy na kliencie adres resolvera na adres naszego routera to zabezpieczymy taki ruch DNS klienta. Teraz wyglądać to może tak:

Już nieco lepiej pod względem bezpieczeństwa. Pozostaje jednak problem: co jeśli nie mam dostępu do klientów? Jeśli to są zmieniające się w naszej sieci LAN laptopy czy urządzenia mobilne sprawę możemy załatwić opcją 6 serwera DHCP. W tym wypadku host kiedy uzyska adres IP z naszego DHCP otrzyma także adres serwera DNS i może nim być nasz RouterOS. Co jednak z hostami, które nie korzystają z DHCP? Co z hostami, na których użytkownicy samodzielnie mogą wprowadzać dowolne zmiany? Rozwiązaniem będzie blokada ruchu DNS i przekierowanie jej do naszego resolvera na RouterOS.

Nowa konfiguracja na kliencie:

Konfiguracja na RouterOS

Czyli klient zadaje pytanie DNS lokalnemu serwerowi (tutaj nasz RouterOS) a on w imieniu klienta zadaje pytanie publicznemu serwerowi DNS. Nadal nie jest ruch szyfrowany!

Ponownie popatrzmy na połączenia sieciowe

Od klienta do RouterOS po sieci LAN:

Teraz klient już nie wysyła zapytań DNS do publicznego serwera DNS ale do lokalnego, którym jest nasz router.

Od RouterOS do publicznego DNS po Internecie:

Router wysyła zapytanie DNS do serwera Google (bo taki został mu wcześniej ustawiony) na port 53 ptotokołu UDP i to też nie jest szyfrowane. Włączymy teraz szybko szyfrowanie tego ruchu:

Dla pewności wyczyścimy bufor DNS (przycisk Cache)

Z klienta ponownie zadamy zapytanie DNS i patrzymy na połączenia od strony WAN:

Jak widać teraz router zadaje pytanie do Cloudflare (1.1.1.1) ale jest ono już w postaci zaszyfrowanej. Więcej tutaj.

Uwaga: samo włączenie tego szyfrowania nie powoduje, że wszystkie hosty będą z niego korzystać. Mogą ale nie muszą. Jeśli na naszym Linux ponownie zmienimy DNS na np. 1.1.1.1 to połączenia DNS będą realizowane w sposób nieszyfrowany. Zmieniamy zatem wpis w /etc/resolv.con na:

Sprawdź samodzielnie jak wyglądają teraz połączenia z RouterOS i z Linux. Co najważniejsze można zadawać pytania i uzyskiwać odpowiedź z publicznego DNS. Zaraz zrobimy tak, że to nie będzie możliwe.

Blokada i przekierowanie ruchu DNS
Załóżmy, że na Linux nie mamy oprogramowania szyfrującego ruch DNS ale chcemy takowe rozwiązanie wdrożyć. Mało tego: chcemy aby każdy host nie mógł bezpośrednio, bez szyfrowania zadawać pytań do publicznych serwerów DNS. Przygotujemy zatem szyfrowanie ruchu DNS na naszym routerze (RouterOS), zablokujemy ruch DNS z LAN do WAN i ustawimy przekierowanie zapytań DNS. Będzie ono działało tak, że kiedy klient wyśle zapytanie o adres IP nazwy domenowej do publicznego serwera nasz RouterOS przechwyci je, zablokuje i przekieruje do swojego wewnętrznego resolvera. A ten zada pytanie publicznemu DNS ale w sposób już szyfrowany.

Blokada połączeń DNS przechodzących przez router
Taką blokadę ustawimy na łańcuchu forward routera. Poniżej przykład z konsoli.

# /ip firewall filter add action=drop chain=forward dst-port=53 protocol=udp

To bardzo ogólna reguła i zabrania ruchu UDP docelowy port 53 w obie strony na routerze. Możemy ją doprecyzować zabraniając tylko ruchu z LAN do WAN czy inaczej.

Schemat działania teraz mamy taki:

Sprawdzimy teraz co z zapytaniami. Na Linux wydajemy polecenie ping www.wp.pl, na RouterOS obserwujemy połączenia:

z LAN brak połączeń:

Firewall reguła #1 złapała jakieś pakiety i zablokowała je ponieważ były to pakiety UDP cel port 53 przechodzące (forward) przez router:

Zatem teraz nikt z sieci LAN nie skorzysta z publicznego DNS po standardowym połączeniu (UDP/53). Adres IP serwera DNS nie jest istotny, wycięliśmy ruch na bazie protokołu i portu. Oczywiście jest teraz klient zapyta o nazwę DNS bezpośrednio nasz router to odpowiedź dostanie. Aby to zrobić trzeba na kliencie zmienić adres serwera DNS na 192.168.0.1 czyli interfejs LAN naszego routera. Ale na razie zostawmy naszą konfigurację, na Linux brak odpowiedzi na zapytanie DNS.

Przy okazji: w tej sytuacji koniecznie trzeba zabronić dostępu do DNS na RouterOS od strony WAN (tutaj ether1):

# /ip firewall filter add action=drop chain=input dst-port=53 in-interface=ether1 protocol=udp

Przekierowanie zapytań DNS
Teraz czas na wykonanie przekierowania: wszystko co z sieci LAN przechodzi (forward) przez nasz router i jest protokołem UDP na port docelowy 53 jest blokowane. Ten ruch „złapiemy” i przekierujemy do lokalnego resolvera działającego na RouterOS. Dzięki temu klient nawet jeśli będzie miał skonfigurowany adres publicznego DNS nie wspierającego szyfrowania dostanie odpowiedź z serwera lokalnego (nasz RouterOS). Ten z kolei zadaje pytanie zaszyfrowane do wybranego publicznego DNS.

Aby umożliwić automatyczne przekierowanie do lokalnego DNS uprzednio zablokowanego pytania dodamy nową regułę firewall do tablicy NAT

# /ip firewall nat add action=dst-nat chain=dstnat dst-port=53 in-interface=ether2 log=yes protocol=udp to-addresses=192.168.0.1 to-ports=53

Reguła ta przechwytuje ruch protokołu UDP na port 53 który wchodzi na interfejs ether2 i zamiast przekazać go do NAT celem wysłania do Internetu przekieruje na adres 192.168.0.1 port 53. Jest to oczywiście adres LAN naszego routera.

Schemat połączeń teraz wygląda tak:

Sprawdzamy z klienta czy działa:

W połączeniach widać:

Podsumowanie
Zablokowano ruch DNS przechodzący przez router, zablokowano zapytania DNS od strony WAN oraz przekierowano cały ruch DNS z sieci LAN do Internetu do lokalnego serwera DNS. Jak widać po regule firewall może to być dowolna maszyna w sieci LAN.

Szyfrowanie ruchu DNS za pomocą RouterOS

Napisane przez Igor Brzeżek on 8 marca 2025
Napisane w: Bezpieczeństwo, MikroTik, Sieci.

RouterOS i szyfrowane połączenia DNS
Nowe wersje RouterOS posiadają wsparcie dla szyfrowanych połączeń DNS. Szyfrowanie odbywa się za pomocą HTTPS czyli jest to DNS over HTTPS (DoH). Pamiętaj, że standardowo ruch DNS *nie* jest szyfrowany!
Opcja /IP/DNS umożliwia obsługę klienta jaki i serwera DNS
1. Klient DNS
Jak każdy system z protokołem IP RouterOS posiadaa klienta DNS pozwalającego zmieniać nazwy domenowe na adresy IP.
– aby ustawić serwery DNS dla naszego RouterOS idziemy do menu /IP/DNS
 
– możemy tu podać kilka serwerów, mogą być lokalne jak i w sieci Internet
– w polu Cache Size określamy jak duży bufor DNS będzie wspierany przez nasz RouterOS
– jeśli nasz RouterOS obsługuje wielu klientów warto zwiększyć tą wartość
– nasz RouterOS jest klientem DNS ale także może pełnić rolę bufora zapytań DNS dla hostów w naszej sieci przyspieszając rozwiązywanie nazw DNS–>IP
– aby włączyć buforowanie zapytań (i tym samym stać się lokalnym serwerem DNS) zaznaczymy opcję „Allow Remote Requests”
– od tego momentu hosty w sieci LAN mogą korzystać z naszego RouterOS jak z serwera DNS
– standardowo połączenie klienta do naszego RouterOS jak i RouterOS do serwera DNS nie jest szyfrowane i to może być poważnym problemem w kwestii bezpieczeństwa naszego IT
2. Połączenia szyfrowane
– powyższe połączenia *nie* są szyfrowane
– aby włączyć szyfrowanie trzeba ustawić opcję ‚Use DoH Server’
– możemy podać jeden z publicznych adresów serwerów wspierających szyfrowanie np. Cloudflare:
CloudFlare
https://1.1.1.1/dns-query
 
 – po zatwierdzeniu opcja ta ma przewagę nad polem ‚Servers’ czyli jeśli tylko połączenie szyfrowane może być zestawione to podane wyżej serwery nie będą używane
– sprawdzamy czy działa za pomocą wbudowanej konsoli:
Inny dostawca szyfrowanego DNS
Zamiast Cloudflare możemy oczywiście zastosować inny serwer DNS potrafiący szyfrować połączenia np. OpenDNS, który ma dodatkowo funkcję filtrowania treści po nazwach DNS. Proste ale na początek dobre zabezpieczenie z serii kontroli rodzicielskiej. W tym wypadku pole Use DoH Server ma zawartość taką:
https://doh.opendns.com/dns-query
Ponieważ posługujemy się tu adresem DNS zanim będziemy do niego mieli dostęp trzeba dodać statyczny wpis kierujący pod odpowiedni adres IP:
– W oknie /IP/DNS klikamy na Static
– W oknie jakie się pojawi klikamy w niebeski plus i dodajemy nowy wpis:
 
– Zatwierdzamy OK
– Teraz możemy założyć konto w serwisie https://opendns.com/ celem włączenie filtrowania „niewłaściwych” treści. Poniżej fragment konfiguracji konta OpenDNS:
 
3. Certyfikat połączenia
Samo szyfrowanie ruchu DNS to mało. Choć zapewnia bezpieczeństwo transmitowanych zapytań i odpowiedzi to nie gwarantuje, że podłączamy się do zaufanego serwera. Funkcjonalność taką daje certyfikat serwera DNS, podobnie jak certyfikat połączenia HTTPS. Podniesie to bezpieczeństwo korzystania z danych dostarczanych z serwera DNS czyli odpowiedzi na zapytania.
sposób a)
– w przeglądarce wchodzimy na stronę serwera DNS (tego z pola DoH) i pobieramy jego certyfikat (oczywiście jeśli korzystasz z innego dostawcy DNS musisz wejść na jego serwis)
 
– klikamy w kłódkę i „Połączenie jest bezpieczne’
 
– kolejno klikamy w ‚Certyfikat jest ważny’
– w oknie jakie się pojawi klikamy w zakładkę Szczegóły i przycisk Eksportuj
– zapisujemy plik certyfikatu np. pod nazwą: cloudflare-dns.com
– otwieramy /Files w aplikacji WinBox i przeciągamy tam powyższy plik
 
– idziemy do do sekcji /System/Certificates
– klikamy w Import
  
– wybieramy wcześniej wgrany do /Files plik
– importujemy klikając Import
   
– certyfikat pojawi się na liście certyfikatów znanych naszemu RouterOS i jak widać jest ważny 90 dni
  
– pamiętaj, że certyfikat ma datę ważności po której powyższe czynności trzeba powtórzyć
– w sekcji /IP/DNS włączamy sprawdzanie certyfikatów i zatwierdzamy klikając Apply
– patrzymy w logi i pingujemy z konsoli np. adres: wp.pl
– jeśli certyfikat jej poprawny uzyskamy odpowiedź na pinga
– celem sprawdzenia czy weryfikacja certyfikatów działa włączamy logi
– w terminalu WinBox pingujemy dowolny host
– jeśli w logach pojawi się błąd nazwa hosta nie zostanie rozwiązana na adres IP jak niżej:
– problemem jest to, że nasz RouterOS choć posiada certyfikat samego serwera to może go zweryfikować ponieważ nie posiada certyfikatu instytucji nadrzędnej (czyli wydającej certyfikat dla DNS CloudFlare)
– idziemy zatem dalej w naszej konfiguracji aby wszystko zadziałało:
sposób b)
– ustawiamy serwer DNS na dowolny ale działający koniecznie po adresie IP, wyłączamy opcję weryfikacji certyfikatów DoH
 
– używając konsoli pobieramy plik certyfikatów głównych urzędów certyfikacyjnych tzw. CA za pomocą poleceń
>/tool fetch url=https://curl.se/ca/cacert.pem
>/certificate import file-name=cacert.pem passphrase=””
– certyfikaty pojawią się w /System/Certificates
– usuwamy wpis 1.1.1.1 z pola Servers, włączamy opcję DoH + sprawdzanie certyfikatów i zatwierdzamy
 
– ponownie testujemy z konsoli i teraz działa
3.1 Automatyczna aktualizacja certyfikatów
Aby nasze certyfikaty były zawsze aktualnie można ustawić ich automatyczne pobieranie np. co dobę
– tworzymy w sekcji /System/Script skrypt o nazwie np. „DNS_DoH_pobranie_certyfikatow” i zawartości jak niżej
– Wywołanie skryptu dodamy do /System/Schedule (poniżej ustawione na uruchamianie skryptu codziennie o 02:00:00)

Analiza ruchu DNS na systemie RouterOS

Napisane przez Igor Brzeżek on 8 marca 2025
Napisane w: Bezpieczeństwo, MikroTik, Sieci.

Zakłada się, że wiesz jak zainstalować maszynę wirtualną z RouterOS i Linux oraz jak skonfigurować sieć oraz co to jest DNS.

1. DNS i RouterOS
Zestaw połączenia zgodne z poniższym schematem. Możesz użyć GNS3

Skonfiguruj dwie maszyny wirtualne jedną z RouterOS druga z Linux/Windows, bez znaczenia.

2. Konfiguracja ustawień IP oraz DNS

RouterOS
Na systemie RouterOS skonfiguruj interfejsy sieciowe. Od strony WAN uzyskaj adres z DHCP albo
wprowadź ręcznie. Wykonasz to w WinBox z menu /IP/Addresses. Przykładowo jak niżej:

Skonfiguruj bramę domyślną

Ustaw adres serwera DNS oraz włącz buforowanie zapytań od klientów sieci LAN

Sprawdzamy czy działa z konsoli RouterOS:

Ponieważ nasz ROS jest routerem dla sieci LAN włączamy na nim usługę NAT (z konsoli)

/ip firewall nat add action=masquerade chain=srcnat out-interface=ether1

Linux
Na systemie Linux także ustal adresację IP. Za pomocą poleceń konsoli zrobisz to tak (jako root):

#ip address add 192.168.0.2/24 dev enp0s3
#ip route add default via 192.168.0.1
#cat nameserver 1.1.1.1 > /etc/resolv.conf

Sprawdzamy konfiguracje i czy działa

#ip a

#ping wp.pl

Działa ale taki ruch zapytań nie jest szyfrowany co bardzo łatwo można sprawdzić za pomocą podsłuchiwania sieci np. programem Wireshark lub wbudowanym w RouterOS snifferem.

Przechwycenie ruchu zapytań i odpowiedzi DNS

Na naszym RouterOS
– Z menu Tools/Packet sniffer otwieramy okno sniffera
– Ustawiamy jak niżej
— pamięć 8M
— nazwa pliku dns.pacp
— limit wielkości pliki około 32M

– Włączamy podsłuch na interfejsie LAN (w tym przykładzie to ether2 o adresie 192.168.0.1) klikając w Apply i kolejno w Start

Z konsoli systemu Linux wysyłamy „pinga” do dowolnego adresu domenowego

#ping -c 1 www.wp.pl

Zatrzymujemy przechwytywanie na RouterOS klikając w Stop. Utworzony plik (/Files) przenosimy do komputera hosta i wczytujemy do Wireshark (z WinBox możemy przenieść myszką ten plik bezpośrednio do okna Wireshark).

Po wczytaniu do Wireshark widok poniższy:

Ponieważ ruch sieciowy był minimalny nie musimy stosować filtrów. Pakiet numer 5 i 6 to pytania z systemu Linux do serwera DNS znajdującego się do adresem 1.1.1.1 (bo tak Linux był ustawiony). Z jakiego powodu mamy dwa pytania choć zadane było jedno? Ponieważ nasz Linux ma włączony stos IPv6. Pierwsze zapytanie jest o rekord A protokołu IPv4 a drugie o rekord AAAA protokołu IPv6. Pakiety 7 i 8 to odpowiedzi na powyższe pytania. Jak widać zarówno zapytania jak i odpowiedzi przesyłane są tekstem jawnym.

W perspektywie bezpieczeństwa to bardzo niedobrze. Ten ruch jest routowany przez nasz ROS do serwera Cloudflare, przez nie naszą sieć czyli przez Internet. Jest zatem wiele możliwości podejrzenia takiego ruchu, a co gorsza przesłania nam spreparowanej odpowiedzi z innym adresem IP. Jeśli docelowy serwis WWW zostanie dobrze podrobiony możemy dać się nabrać i wprowadzić tam nasze login i hasło tym samym przekazując je napastnikowi.

Jeśli chcesz możesz teraz powtórzyć przechwytywanie ruchu ale na interfejsie routera od strony WAN. W tym wypadku będziemy mieli znaczenie więcej przechwyconych pakietów ponieważ od strony WAN pracuje znacznie więcej maszyn (w naszym przykładzie).

Kilka sekund przechwytywania dało prawie 800 pakietów. Aby wyłowić co nas interesuje użyjemy filtrowania. Nasz filtr do „dns” i w wynikach widzimy kilka pakietów. Pakiet numer 562 zawiera odpowiedź dla IPv4

Po tej stornie routera ruch DNS także nie jest filtrowany.

3. Szyfrowanie ruchu
Na routerze włączymy teraz szyfrowanie ruchu DNS. Proces opisany jest tutaj. W tym wypadku jednak musimy zmienić teraz konfigurację klienta (resolvera) DNS na kliencie czyli naszym Linux. W pliku /etc/resolv.conf zmieniamy adres DNS z 1.1.1.1 na 192.168.0.1.

Aby powyższa konfiguracja zadziałała na RouterOS trzeba włączyć opcję Allow Remote Request na zakładce DNS (o ile tego nie wykonano wcześniej).

Jeśli router ma włączony firewall to zapewne trzeba dodać regułę pozwalającą na dostęp do jego portu UDP/53 od strony LAN. Jest to port, na którym nasłuchuje usługa DNS. Przykład takiej reguły poniżej:

#/ip firewall filter add action=accept chain=input dst-port=53 in-interface=ether2 protocol=udp

Po konfiguracji szyfrowania DNS ponownie wykonamy dwa przechwytywania ruchu: od strony LAN i WAN

4. Przechwytywanie ruchu DNS po szyfrowaniu
Proces przechwytywania jest identyczny jak poprzedni zatem pokazane są poniżej tylko wyniki w Wireshark

Od strony LAN

Jak widać tutaj nic się nie zmieniło, nadal mamy ruch nieszyfrowany. Tylko teraz nasz Linux zapytania wysyła nie bezpośrednio do Cloudflare a do naszego lokalnego resolvera jakim jest nasz RouterOS pod adresem 192.168.0.2. Ponieważ to ruch w sieci lokalnej może nie będzie konieczne szyfrowanie. Ale jeśli i ten odcinek chcemy zabezpieczyć nie pozostaje nic innego jak zainstalować na kliencie odpowiednie oprogramowanie szyfrujące ruch DNS. O tym temacie w innym module/artykule.

Przy okazji 1: reguła firewall złapała zapytanie z systemu LInux

Przy okazji 2: w buforze naszego lokalnego DNS pojawiły się wpisy adresów poszukiwanych przez Linux:

Przy okazji 3: w tej sytuacji koniecznie trzeba zabronić dostępu do DNS na RouterOS od strony WAN (tutaj ether1):

# /ip firewall filter add action=drop chain=input dst-port=53 in-interface=ether1 protocol=udp

Jeśli teraz do czasu życie takiego wpisu w buforze ktoś zapyta o tą samą nazwę domenową to nasz RouterOS odpowie z odwzorowaniem nazwa–>IP z bufora, nie będzie musiał wysyłać zapytania do DNS w sieci Internet.

Od strony WAN
Także tym razem plik z przechwyconym ruchem sieciowym zawiera dużo danych, zastosujemy filtr DNS jak poprzednio:

Pusto! Z jakiego powodu? Przecież zapytanie było wysłane do DNS pod adresem 1.1.1.1. Powodem jest to, że teraz ruch DSN jest szyfrowany. Sprawdzimy innym filtrem, a mianowicie filtrem adresu IP. Wiemy, że zapytania maja być kierowane do adresu 1.1.1.1, zatem:

Widać, że nasz host 192.168.7.191 wysyła jakiś ruch (szyfrowany) do 1.1.1.1 i uzyskuje odpowiedzi. Wszystko jest zaszyfrowane zatem do środka nie zajrzymy. Miejmy nadzieję, że zły pan czy zła pani także nie zobaczą co tam jest 🙂

Podsumowanie
W pierwszej części pokazano nieszyfrowany ruch zapytań i odpowiedzi DNS, w drugiej ten ruch został zaszyfrowany. Weź pod uwagę, że szyfrujemy od routera przez Internet do celu (w stronę powrotną też). W sieci LAN ruch DNS nie jest szyfrowany. Ma to wady i zalety.

Zaletą jest to, że możemy teraz dodać konfigurację blokady połączeń DNS nieszyfrowanych z naszej sieci LAN i przekierować jest do routera, który ten ruch przechwyci i pośle w świat już w postaci zaszyfrowanej. Jak to zrobić opisano tutaj. W takim wypadku żaden host z naszej sieci LAN nie będzie mógł wysyłać nieszyfrowanych zapytań do sieci Internet. Oczywiście mowa o konfiguracji standardowej czyli połączeniach UDP na port 53.

Wadą jest to, że jeśli powyższej blokady nie zrobimy to tylko hosty korzystające z naszego RouterOS jako serwera DNS będą chronione w Internecie szyfrowanym ruchem DNS.

MikroTik RouterOS – Generator pakietów

Napisane przez Igor Brzeżek on 26 lutego 2025
Napisane w: MikroTik, Sieci.

Zadanie
Analiza protokołów MAC, IP, UDP oraz przepustowości
Używając oprogramowanie RouterOS wygenerować ruch sieciowy UDP z portu 10000 -> 20000, TTL3, 1000PPS, rozmiar pakietu 1024 bajty.
– zakładamy, że na hoście docelowym nie pracuje żadna usługa na porcie UDP 20000
– jakie warstwy i protokoły modelu OSI biorą udział w takim ruchu
– jakiej wielkości są dane w każdej warstwie OSI biorącej udział w takim ruchu
– jakiej wielkości są nagłówki pakietów a jakie sekcje danych
– jakiej odpowiedzi udziela host na taki pakiet
– jaką przepustowość konsumuje taki ruch
– ile % tego ruchu przenieść może faktyczne dane użytkownika
– jakie jest obciążenie routera i z czego wynika
– czy z hosta jest generowana do nadawcy jakaś odpowiedź na każdy pakiet
– jeśli tak to jaki i w jakim celu
– kolejno sprawdzić tan sam rodzaj ruchu ale na port z pracującą usługą np. serwer DNS czy coś innego
– czy host

1. Konfiguracja Trafic Generator na RouterOS
1a. Budowa pakietu
1b. Przygotowanie strumienia danych
2. Uruchomienie transmisji
3. Przechwycenie ruchu na hoście docelowym
4. Analiza przechwyconych danych
5. Analiza transferu podczas działania generatora

Tworzymy sieć jak niżej

rysunek 1

Lub w przypadku radia (będzie to miało znaczenie w dalszej części)

rysunek 2

Na urządzeniu R1 mamy MikroTik RouterOS, na Linux mmy dowolny system Linux z zainstalowanym analizatorem pakietów np Wireshark.

1. Konfiguracja Trafic Generator na RouterOS (R1)
1a. Budowa pakietu
– Z menu Tool wybieramy Traffic Gnerator
– Celem przygotowania pakietu zgodnie z założeniami klikamy w Packet Template i dodajmy nowy szablon pakietu

Zakładka General

— ustalamy nazwę
— stos nagłówków zostawiamy bez zmian (tak jak zdefiniowane są z OSI: najniżej MAC, nad nim IP i nad nim UDP)
— aby pole danych pakietu było wypełnione danymi do łatwej identyfikacji ustalimy je na powtarzające się ciągi FA (szesnastkowo)
— inne opcje tej pozycji pozwolą wygenerować dane w sposób losowy ale to zwiększy obciążenie generatora a tym samym bardziej może wpłynąć na samo generowanie ruchu zwłaszcza gdy jego wolumeny będzie duży; te dane zobaczymy w polu danych przechwyconego przez np Wireshark pakietu (te dane znajdą się w polu danych protokołu najwyższej warstwy w naszej konfiguracji czyli w tym wypadku UDP)
— ustalamy interfejs sieciowy, którym ruch będzie wysyłany (w naszym przypadku jest to interfejs A zaznaczony na schematach sieci), musi to być interfejs kierujący do urządzenia docelowego

W naszym przypadku enkapsulacja będzie wyglądała jak niżej:

Dane z wcześniej ustalonego pola trafią do danych pakietu UDP

Teraz trzeba ustalić dane protokołów kolejnych warstw wykorzystywanych przez nasz generator

Zakładka MAC

– W polu Dst należy wpisać adres MAC (sprzętowy) urządzenia docelowego
– W naszym wypadku będzie to interfejs B w przypadku sieci przewodowej
– Adres MAC tegoż interfejsu sprawdzimy łatwo:

#ip address show

– Problem się jednak pojawi gdy do naszego Linux (czy co tam mamy na urządzeniu docelowym) podłączeni jesteśmy radiem (lub przez inne routery) co pokazano na rysunku 2
– W zależności od trybu radiowego możemy być zmuszeni do podania adresu MAC interfejsu Y radia 2 (urządzenia radiowe często maskują swoim adresem MAC interfejsu radiowego interfejsy podłączone do nich po LAN)
– Jeśli nie wiemy za jakim adresem MAC znajduje się nasze urządzenie (w sieci radiowej) możemy to łatwo sprawdzić.
— otwieramy terminal
— pingujemy urządzenie docelowe
— w menu IP/Arp szukamy tegoż wpisu
— znajdziemy tu adres MAC urządzenia docelowego widziany z perspektywy naszego routera R1

— dwukrotnie klikamy na wpisie w tablicy ARP, zaznaczamy adres MAC, prawym myszki, Copy i wklejamy do pola Dst.

– Podajemy zatem adres MAC docelowy

Zakładka IP

– Tutaj podajemy adres IP docelowy
– Jeśli do miejsca docelowego (z naszego segmentu) prowadzi kilka tras można jeszcze podać Gateway czyli adres IP routera prowadzącego do celu
– Ustalamy wartość TTL na 3

Zakładka UDP

– Tutaj trzeba podać z porty źródłowe oraz docelowe
– Można podać zakres np 10000-20000

1b. Przygotowanie strumienia danych
– W generatorze pakietów klikamy w Streams i dodajmy nowy strumień (niebieski plus)
– Ustalamy nazwę np streamUDP, rozmiar pakietu na 1024 bajty
– Ilość pakietów na sekundę (PPS) na początek ustalamy na 1
– Z listy TX Templates wybieramy przygotowany wcześniej szablon pakietu „pakietTestowyUDP”
– Zatwierdzamy ustawienia

– Na listach szablonów oraz strumieni powinniśmy teraz mieć po jednym wpisie

2. Uruchomienie transmisji
Zanim uruchomimy generator przygotujemy sobie klienta
– Na naszym Linux włączamy przechwytywania pakietów (jeśli maszyna ma kilka interfejsów zwróć uwagę czy został wybrany właściwy)
– Aby ograniczyć ich ilość w danych wynikowych możemy podać filtr przechwytywania np. „host 192.168.55.2” gdzie podany IP jest adresem generatora pakietów
– Uruchamiamy strumień danych z generatora (przycisk Start) wybierając wcześniej przygotowany strumień

3. Przechwycenie ruchu na hoście docelowym
Na docelowej maszynie uruchamiamy przechwytywanie pakietów.
– Na analizatorze Wireshark obserwujemy pojawiające się pakiety, wystarczy przechwycić kilka

– Jak widać mamy tu wszystkie założone dane
– Kolor pakietu czerwony wskazuje, że według Wireshark jest z nim coś nie tak, zaraz sprawdzimy co
– Na każdy pakiet, który host otrzymał wysyła odpowiedź protokołu ICMP
– Analizujemy jeden pakiet od generatora klikając go
– Przeanalizujemy go w trzech warstwach: MAC, IP, UDP (bo tak pakiet był w generatorze skonstruowany)

4. Analiza przechwyconych danych
> Warstwa MAC (zaznaczona czerwoną ramką):

– Mamy tu trzy istotne elementy
— adres MAC docelowy (R1)
— adres MAC źródłowy (podany w generatorze, hosta docelowego)
– Typ przenoszonego protokołu (0x0800 czyli IP) także ustalony w generatorze

Budowa oraz kolejność danych jest zgodna ze standardem IEEE 802.3.

Nie widzimy tu jedynie pół „zdejmowanych” przez kartę sieciową: preambuła, SFD (o ile są) oraz FCS.
W pierwszej linii may informację o rozmiarze ramki (pola: adresy, typ i dane) równym 1024 bajty, to dokładnie tyle, ile zadaliśmy w generatorze, sekcja strumień:

> Warstwa IP

– Zgodnie z nagłówkiem IP mamy tu:
— wersje
— długość nagłówka
— pola DSCP
— całkowitą długość pakietu IP (nagłówek i dane) 1010, w stosunku do ramki to mniej o 14 bajtów co pasuje ponieważ jej nagłówek do (2×6)+2 (adresy oraz typ protokołu)
— identyfikator
— flagi
— ofset fragmentacji
— pole TTL (tutaj ma wartość 3 ponieważ to także było ustalone w generatorze)

 

— informacje o protokole warstwy wyższej
— suma kontrolna nagłówka
— adres źródłowy oraz docelowy

Długość nagłówka IP to 20 bajtów czyli odejmując od całkowitej wielkości ramki 1024 nagłówek ramki Ethernet oraz owe 20 bajtów nagłówka IP uzyskamy 990. Tyle zostaje na na dane przenoszone przez datagram IP czyli nasz pakiet UDP musi zmieścić się z 990 bajtach. Trzeba pamiętać, że on także ma nagłówek, ale o tym później.

Poniżej widok nagłówka IP (geeksforgeeks.org)

> Warstwa UDP (zaznaczona czerwoną ramką)

– Zgodnie z nagłówkiem UDP mamy tu:
— port źródłowy
— port docelowy
— długość całego pakietu
— suma kontrolna

Porty są zgodne z założeniami generatora

– Zaraz na nagłówkiem (o bajtów) mamy pole danych o rozmiarze 990-8 bajtów czyli 982 bajty. Zawartość pola danych także jest zgodna z danymi generatora.

Odpowiedzią hosta na każdy otrzymany na port 20000 pakiet jest komunikat ICMP o nieosiągalności portu docelowego. Jest to zrozumiałe, ponieważ port docelowy na hoście nie jest czynny innymi słowy żaden program nie nasłuchuje na nim. Poniżej przykład: w ramce nr 5 jest zapytanie do portu 20000, w ramce kolejnej czyli nr 5 mamy informację od protokołu ICMP o nieosiągalności portu

Zawartość pakietu ICMP: Destnation/Port unreachable

Jeśli teraz na hoście docelowym uruchomimy dowolną usługę na porcie 20000 np za pomocą programu netcat

#sudo netcat -l -u 192.168.55.105 20000

To host odpowiadać pakietem ICMP już nie będzie:

Jak widać mamy same zapytania ponieważ pakiet został odebrany przez netcat. Z jakiego powodu nie ma żadnej odpowiedzi? Po pierwsze netcat odebrał pakiet a po drugi to protokół UDP więc zakłada się, że nadawca nie oczekuje odpowiedzi (ruch bezpołączeniowy).

5. Analiza transferu podczas działania generatora
– Konfigurujemy teraz generator ponownie tym razem ustalając 1000 PPS (nie włączając na razie transmisji)
– Jaki wolumen ruchu zostanie wygenerowany
– Jak można to policzyć:

Każdy pakiet (ramka Ethernet w tym wypadku) to 1024 bajty bo tak mówi generator. Daje to 1024*8 bitów = 8192 bitów na ramkę/pakiet. Generowanie 1000 pakietów na sekundę to 1000 ramek na sekundę (ponieważ to UDP więc może nie być ruchu powrotnego) co daje 1000*1024 bajty = 1024000 bajtów na sekundę co daje 8192000 bitów na sekundę. Dzieląc to przez 8 (8 bitów = 1 bajt) dostaniemy 1020000 B/s. Dzieląc to przez 1024 dostaniemy wynik w kB/sek czyli 1000 kB/s. Jeśli chcemy wynik otrzymać w Mbps (megabity na sekundę) to wartość w b/s 8192000 trzeba podzielić przez „informatyczny” maga czyli 1024*1024: 8192000 / (1024*1024) = 7,8125 Mbps.

– Uruchamiamy zatem transmisje pakietów z generatora
– Na hoście docelowym uruchamiamy program ‚nload’ dla interfejsu odbierającego dane

– Dokładnie taką wartość pokazuje ‚nload’
– Patrząc na RouterOS

– Różnica może wynikać z innego rodzaju ruchu, który jeszcze jest na routerze

– Zaobserwujmy jeszcze obciążenie samego routera podczas transmisji:

– Jest w okolicach 30-40%

Podsumowanie informacji o rozmiarach nagłówków
OSI2: MAC – 6+6+2 = 14
OSI3: IP  – 20 (https://www.geeksforgeeks.org/introduction-and-ipv4-datagram-header/)
OSI4: UDP – 8 (https://www.geeksforgeeks.org/user-datagram-protocol-udp/?ref=lbp)
reszta to dane, cały pakiet miał mieć 1024 bajty więc:
1024 – 14 – 20 – 8 = 982, tyle pokazuje Wireshark jako dane

Maszyna wirtualna dla RouterOS w wersji ROS v6/7

Napisane przez Igor Brzeżek on 19 lutego 2025
Napisane w: MikroTik, Wirtualizacja.

RouterOS wersja 6/7 x86
Wersja ROS 6 lub 7 jest dostosowana do instalacji na różnych urządzeniach takich jak RouterBoard lub na maszynie x86. Poniżej opis utworzenia maszyny wirtualnej dla tego systemu.

– Pobieramy wybraną wersją RouterOS 6 lub 7 w postaci obrazu instalacyjnego ISO:

– Tworzymy nową maszynę wirtualną

– Opcje jak niżej
— Folder: to katalog w którym VirtualBox tworzy podkatalogi dla każdej maszyny wirtualnej (nazwa podkatalogu jest zgodna z nazwą maszyny)
— ISO Image: pobrany wcześniej obraz instalacyjny systemu operacyjnego, tutaj RouterOS

– Pamięć RAM minimum 128 MB

– W sekcji wyboru dysku twardego zaznaczamy opcje utworzenia nowego dysku (rozmiar minimum 128 MB, miejsce utworzenia domyślnie katalog maszyny):

– Klikamy w przycisk Zakończ tym samym tworząc maszynę wirtualną
– Teraz maszynę uruchamiamy i instalujemy RouterOS wybierając odpowiednie pakiety

– Aby rozpocząć instalację trzeba nacisnąć klawisz „i”, po chwili gotowe
– Maszyna gotowa do uruchomienia (pierwsze uruchomienie trochę trwa):

– Można się zalogować admin bez hasła (trzeba je utworzyć przy pierwszym logowaniu)

Maszyna wirtualna dla RouterOS w wersji CHR

Napisane przez Igor Brzeżek on 19 lutego 2025
Napisane w: MikroTik, Wirtualizacja.

RouterOS wersja CHR
Wersja ja Clou Hosted Router jest dostosowana do pracy w środowisku zwirtualizaownym. Dystrybuowana jest w postaci pliku wirualnego dysku twardego. Poniżej opis utworzenia maszyny wirtualnej dla tego systemu

– Pobieramy wybraną wersją RouterOS CHR ( w tym opisie dla VirtualBox)
Wersja 7 różni się głownie tym od 6, że obsługuje kontenery. Pobieramy zatem wersję v7

– Pobrany plik rozpakujemy i mamy plik:

– Tworzymy nową maszynę wirtualną

– Opcje jak niżej

– Pamięć RAM 128 MB

– W sekcji wyboru dysku twardego zaznaczamy opcje utworzenia maszyny bez dysku (w tym celu, aby dodać go później, kiedy katalog maszyny zostanie już utworzony – chodzi o porządek w plikach, nic innego)

– Klikamy w przycisk Zakończ tym samym tworząc maszynę wirtualną
– Maszyna się pojawia na liście, klikamy zatem w nią prawym myszki i wybieramy Ustawienia

– Teraz skopiujemy albo przeniesiemy rozpakowany plik do nowoutworzonego katalogu maszyny – gdzie on jest to już Ty musisz wiedzieć, katalog ten wybrany był kilka kroków wcześniej. Wwaga: w tym przykładzie wybrany wcześniej katalog to e:\vm ale to jest ogólny katalog na maszyny wirtualne w moim przypadku, w tym katalogu zostanie utworzony podkatalog zgodny z nazwą tworzonej maszyny i to do tego katalogu trzeba wgrać plik dysku. Poniżej mój układ katalogów

1 – ogólny katalog maszyn VM
2 – katalog utworzony przez konfigurator tejże maszyny (tu wgraj plik dysku)

– Wracamy do okna ustawień i przechodzimy w sekcje Pamięć (1), klikamy w ikonkę dysku z plusem (2)

– W oknie, które się pojawi wybieramy Dodaj

– Teraz wybieramy rozpakowany wcześniej plik wirtualnego dysku

– Klikamy w Choose (albo wybierz jak już przetłumaczą) i OK w oknie konfiguracji maszyny
– Maszyna gotowa do uruchomienia (pierwsze uruchomienie trochę trwa):

– Można się zalogować admin bez hasła (trzeba je utworzyć przy pierwszym logowaniu)

MikroTik – instalacja i generowanie darmowej licencji Level 1

Napisane przez Igor Brzeżek on 7 grudnia 2020
Napisane w: MikroTik.

W części przykładów odwołujemy się do RouterOS jako przydatnego narzędzia sieciowego i diagnostycznego. Poniżej skrócony opis tworzenia maszyny wirtualnej i instalacji tegoż systemu

Instalacja MikroTik RouterOS w VirtualBox
Standardowo po instalacji RouterOS mamy darmową licencję działającą 24h (liczy się czas pracy). Aby podnieść ją do DEMO (LEVEL 1) i cieszyć się systemem bezterminowo trzeba założyć profil na mikrotik.com i kolejno wygenerować klucz licencji. Jest to operacja darmowa.

– pobieramy obraz ISO RouterOS (sekcja x86, wiersz CD Image, ikona dyskietki druga kolumna – wersja „stable”)

– tworzymy maszynę wirtualną (64bit, Debian, 128MB RAM, dysk 128MB)
– dwa interfejsy sieciowe
– podłączamy obraz ISO
– uruchamiamy maszynę wirtualną
– wybieramy z menu instalatora pozycje jak niżej

– klawisz i rozpoczyna instalację
– ustawiamy pierwszy interfejs sieciowy na mostkowany (bridged) drugi na razie na odłączony
– pierwszy interfejs jest połączony z naszą siecią co pozwoli zalogować się do systemu RouterOS
– po instalacji odmontujemy obraz ISO i restartujemy maszynę wirtualną
– po restarcie pojawia się informacja o darmowej licencji i czasie jaki nam pozostał ana pracę w systemie

– w międzyczasie pobieramy program WinBox (32 lub 64 bit w zależności od naszego systemu)

– uruchamiamy go i skanujemy sieć
– nasz RouterOS powinien się pojawić

– klikamy na jego pozycję w kolumnie „MAC Address” w liście i przycisk Connect (połączymy się po adresach MAC ponieważ żaden adres IP nie został jeszcze ustanowiony)
– login admin bez hasła
– teraz z poziomu WinBox można ustawić adresy IP i inne opcje (nalezy w maszynie wirtualnej ustawić odpowiednio interfejsy sieciowe)

Pozyskanie licencji Level 1
– zakładamy konto na mikrotik.com
– logujemy sie do konta
– logujemy się do MT za pomocą WinBox
– kopiujemy klucz „Software ID” menu /System/license

– idziemy do portalu MikroTik
– menu jak niżej

– po prawej wklejamy klucz do pola Software ID
– klikamy Generate
– pojawi się licencja, którą kopiujemy i wklejamy w WinBox za pomocą przycisku Paste Key

– wymagany jest restart RouterOS
– po restarcie mamy licencje Level 1 bezterminową

– teraz patrząc do menu System/License widzimy Level 1

UWAGA: sklonowanie dysku lub wygenerowanie nowego UUID powoduje skasowanie licencji, którą trzeba odnowić.