22T50 7 Kroków Utworzenia Mikro Data Center [konfiguracja MikroTik] cz.6

Data Center FW. OUTPUT FORWARD

Link do artykułu.

0:00 Wprowadzenie

1:26 Topologia

3:54 Stworzenie Reguły

7:37 Reset Liczników

8:33 Analiza Pakietów Przechodzących

12:43 Reguła Forward i dalsza część Konfiguracji

30:57 Podsumowanie

Transkrypcja

Cześć. W dzisiejszej części pokażę trzy ostatnie kroki w tworzeniu takiej bazy dotyczącej Mikro Data Center. Czyli dokończę konfigurację Firewalla w zakresie Chain Forward i Chain Output i na koniec jeszcze skopiuje konfigurację tych nazw list adresów i ich definicji oraz reguł Firewall’owych do kolejnego routera, który pracuje w parze VRRP. Tak, żeby ujednolicić sposób podejścia do reguł Firewall’owych na wypadek awarii dowolnego z tych routerów. Czyli jeżeli nastąpi przełączenie VRRP np. na wypadek awarii albo łącza to żeby wszystkie usługi, które są dostępne w Data Center działały dokładnie w ten sam sposób. Tu jedna uwaga. Zobaczysz za chwilę w materiale na końcu jest sytuacja taka, że musisz dostosować trochę te reguły pomiędzy jednym routerem a drugim. Zgłasza w zakresie tego chain’u input dlatego, że specyficzne adresy się różnią w związku z tym trzeba dostosować odpowiednie reguły. Albo pisać te reguły szerzej tak, żeby były bardziej uniwersalne przy kopiowaniu. To już jest kwestia Twojego wyboru, gdzie stawiasz poprzeczkę pomiędzy poziomem bezpieczeństwa a ilością pracy, którą trzeba włożyć, żeby to wszystko utrzymać.

To jak zwykle zacznę od tego czym się będę dzisiaj zajmował. Tą topologię już znasz z poprzednich odcinków. Konfiguruję dzisiaj Firewalla w Chain’ie czyli w takim procesie output czyli dla pakietów wychodzących. Będę konfigurował MT1-DC-DMZ i reguły, które dotyczą pakietów wychodzących przez interfejsy, które są na tym routerze skonfigurowane. Jeżeli chodzi o to, jak konkretnie wygląda tabela teraz Firewalla na tym MT1-DC-DMZ to zobaczmy. Mam tutaj pokonfigurowane 19 reguł już dotyczących tego Chain’u Input. Mam tu na dole domyślne jeszcze reguły dla sposobu przetwarzania Forward i Output. Dzisiaj Input jak widzisz tutaj już ponieważ tym się zajmowałem ostatnio jest w trybie drop i ma logowanie, jeżeli będą tutaj dodatkowe pakiety się pojawiać, będę sprawdzał i ewentualnie aktualizował tą konfigurację.

Jeżeli chodzi o Output tutaj też mam domyślną regułę na końcu accept i tutaj widać, że też są pakiety, które wpadają w tą regułę. Forward’u narazie nie dotykam. To będzie jakiś kolejny krok. Więc teraz jeżeli chodzi o logowanie to mam tutaj na osobnej zakładce terminal. Oznaczyłem sobie regułę DC-FW-OUTPUT. To jest logowanie na MT1-DC-DMZ w regule Output Default.Wejdę w tą regułę, to tutaj mam logowanie i prefix DC-FW-OUTPUT i dzięki temu mogę zobaczyć te wpisy, które mnie interesują konkretnie w tym zakresie. Jeżeli chodzi o polecenie to log/print follow where message I tutaj ten mój prefix czyli DC-FW-OUTPUT no I jak to sobie tutaj uruchomię to widzę, że pojawiają mi się tutaj pakiety: protokół 89, protokół, który… Czyli to jest jakby enkapsulacja czyli takie wykorzystanie w pakiecie IP protokołu o identyfikatorze 89. To jest pod kątem OSPF’a no i widzę, że z adresu 10.255.255.6 idzie na adres multicastowy z końcówką 5. Czyli widać, że ruch z adresu 6 – to jest jeden z interfejsów Wireguarda, które mam na tym routerze, wysyła pakiety multicastowe i z drugiego interfejsu 18 również takie pakiety multicastowe wychodzą.

W związku z tym teraz muszę skonfigurować regułę, która mówi, że jeżeli będzie wychodził ruch, czyli z chain’u output destynation będzie to multicast OSPF. Czyli ten adres 224.005. No to na taki ruch zezwalam. Tu nawet nie muszę się bardzo ograniczać z jakiego konkretnie adresu będzie szedł ten ruch. No bo tu mówimy o ruchu wychodzącym czyli zakładam, że zawsze będzie ten ruch wychodził z tego routera. WIęc to jest dla mnie ok. Tworzę więc taką regułę Chain Output. Mam tutaj już potworzoną wcześniej w poprzednim odcinku aliasy. Czyli interesuje mnie Dst. adress OSPF-Multicast, to będzie właśnie ten adres multicastowy 224.005 i src adresu nie będę tutaj wymieniał czy w ogóle specyfikował. No i na końcu potrzebuje tylko dać opis OSPF. Zobaczę, że podobne są te opisy, które robiłem wcześniej. Napis mój stworzony zawsze wychodzi tu na dole Multicast Output.

No i ok. Myślę, że dobrze. Teraz go tylko przesunę, najlepiej na górę. Może niech będzie tutaj na samej górze OSPF’a. OSPF Multicast Output bez specyfikowania z jakiego interfejsu do adresu Multicastowego, widać, że trzy pakiety już są tutaj rejestrowane. Teraz skasuje wszystkie liczniki i sprawdzę co mi się tutaj pojawia. Teraz się skupiam na tym output Default bo tu mam akcje acccept i zobaczę czy mi się pojawia jakiś pakiet. Jak widzisz nie pojawia mi się tutaj nic więcej. W związku z tym mogę wejść w tą regułę i teraz zaznaczę akcję Drop. Logowanie narazie zostawię jeszcze jakbym chciał analizować co tutaj będzie się działo, co za pakiety będą dropowane. Mogę teraz jeszcze wrócić na chwilę do tej akcji Input bo jak widzę jest tutaj jeszcze 20 pakietów rejestrowanych. No to zobaczmy w logu co tutaj się dzieje.

Input… Input. Jeżeli chodzi o input to widać, że tutaj idą broadcasty same. Możemy ewentualnie zobaczyć z jakiego Mac adresu src-mac 00.50.00.00.10 I mogę sprawdzić teraz jaki to jest adres, czy gdzie on występuje, na którym porcie i będę w stanie wyłączyć pewnie tego klienta DHCP, który tutaj się pokazuje. No to idziemy i sprawdzamy. Może najpierw sprawdzę na tym switchu, który jest w moim DMZie. Czyli ten. Mnie interesuje tutaj drugi host, czyli to jest na ether5. Do interfejsu 5. No i wszystko jasne, to pyta ten Linux, tu faktycznie mam nie skonfigurowany obecnie adres IP ale go nie potrzebuje, mogę go po prostu narazie wyłączyć. Tego też narazie mogę wyłączyć. No i teraz mogę sprawdzić czy się pojawiają tutaj takie wpisy. Poczekam chwilę, zobaczę czy się jakiś nowy wpis pokaże ale widać już, że nie ma tych zapytań póki co.

No to mogę wrócić teraz do tych liczników. Zresetuje jeszcze raz liczniki i zobaczę, czy się pojawiają jakieś pakiety dla domyślnego wpisu dla input’u i output’u. Forward jak widzisz mimo, że jest accept też się nie pojawia żaden pakiet ale to z tej prostej przyczyny, że narazie jeszcze żadnego ruchu nie wygenerowałem dotyczącego ruchu miedzy hostami, czyli np. między tym Linuxem a hostem w campusie. Wszystkie te polecenia czy te reguły, które tutaj wpisałem dotyczą narazie głównie input’u I output’u czyli konfiguracji, czy ruchu, który jest związany z OSPF’em. Czyli jak widzisz tu opis w zasadzie jest tak VRRP, WireGuard i OSPF. Najwięcej z OSPF’a i ten ruch menagementowy. Plus ustanowione połączenie i to jest w zasadzie wszystko co ja tutaj stworzyłem obecnie. Widać, że jest 0 tutaj narazie pakietów w tym zakresie.

No dobra to mogę przejść w takim razie jeszcze do forward’u czyli przejść do analizowania dla pakietów przechodzących. Co ja bym chciał teraz sprawdzić? To może zróbmy tak: połączę teraz tego Linuxa i sprawdzę czy mam adres IP na vpc11. Spróbuję zapingować DC DMZ – Linux DC DMZ i zobaczę czy przechodzi przez MT1-DC-DMZ i czy otrzymuję odpowiedź od tego hosta. To najpierw sprawdzę czy mam adres IP na tym VPC. Nie mam. Już mam. Teraz do Linuxa. Mam już tutaj konsolę Linuxa ponieważ to jest serwer to nie będę ustawiał adresu z DHCP. Tutaj ustawię adres manualnie i to będzie sieć 10.140.0 z końcówką 1, maska 24 bity, Gateway 254 i DNS.

Teraz będzie mi potrzebny terminal i zobaczę czy ja mogę osiągnąć tego hosta vpc11. Pinguję tutaj od strony DMZ’u. Dobra a teraz zobaczmy czy jestem w stanie zapingować od strony tego hosta. I ruch również przechodzi. To teraz wracam do Firewalla. Jak popatrzymy sobie na Forward Default to jest 14 pakietów. Możemy wejść sobie tutaj teraz, włączyć logowanie, prefix i jeszcze raz zapinguje, żeby wysłać pakiety. Wrócę do Firewalla, logi i teraz będzie mnie interesował Forward. No i widzę, że tutaj pakiety się pojawiły czyli od 10.0.10.11 do 10.140.0.1 idzie ruch protokołem ICMP i jeszcze jest tutaj widać jakaś komunikacja od 10.140.0.1 do 185.125.190.56, czyli do internetu. Generalnie do internetu. 123 port sprawdzę co to jest. To jest NTP czyli liny spróbuje sobie po prostu zsynchronizować czas z internetem. I to jest dla mnie ok.

Chciałbym, żeby z DMZ’u było wyjście z tego serwera do internetu. Tutaj jeżeli chodzi o połączenie ICMP to oczywiście mam tu do wyboru teraz różną granulację reguł. Mogę ograniczyć tą regułę tylko do pingów, czyli do ICMP albo mogę tą regułę opisać w sposób per IP po prostu. No i tutaj każdy może sobie wybrać jakby chciał to realizować. To, co ja tutaj zrobię to zrobię konkretny wpis dotyczący konkretnego protokołu a jak będę uruchamiał kolejne usługi to będę dodawał sobie kolejne wpisy do mojego Firewalla. Czyli teraz tak: potrzebuję dodać sobie… Zobaczmy czy mam w liście tą sieć. Campus1-NET sieć mam. Czyli jak będzie ping szedł z tej sieci do serwera. Tu muszę sobie dodać jeszcze serwer bo tego adresu nie mam. Czyli tutaj DMZ… może tak Linux-DC-DMZ. Tak się zdaje nazywa tutaj Linux-DC-DMZ i tak go nazwę w moim obiekcie. To będzie 10.140.0.1

Może tu wpiszę adres IP też. Ok. Mam obiekt Linux-DC-DMZ. Mogę teraz przejść do reguły Forward. No i teraz jeżeli będzie przechodziło to zapytanie od Campus1-NET do Linux-DC-DMZ dla protokołu ICMP, Wtedy taki ruch będzie akceptowany. Jeszcze może skopiuje tak… i na samą górę. Ok. No i teraz mogę ponownie wykonać to sprawdzenie, czyli pingi w jedną i w drugą stronę. I zobaczę co mi się tutaj pojawia. Pojawia mi się, że z 10.140.0.1 do 11. Tutaj chodzi o to, że standardowo ICMP nie jest stanowym protokołem. Czyli pakiet, który szedł od hosta tutaj pomiędzy tą całą naszą siecią i do tego serwera. Trafiał w tą nową utworzoną regułę na górze ale pakiet, który już wracał od serwera Linux-DC-DMZ i szedł w dół tutaj i ten pakiet już trafiał w domyślną tylko regułę. Ale ponieważ ona ma dalej, że zezwala to pakiet dotarł tutaj na sam koniec. Więc jeżeli teraz chciałbym to ograniczyć w sensie zezwolić na to co chciałbym, żeby było dopuszczone do komunikacji. No to potrzebuje dwie rzeczy zrobić. Zrobić taką regułę dotyczącą ruchu powrotnego czyli tworzę nową regułę Forward i teraz z Linuxa do sieci Campus. Tu Campus1-NET. Ok.

No i teraz mogę zresetować liczniki. Nie mam tu niczego jeżeli chodzi o Forward. Nie ma żadnego pakietu. Pinguję. Z dwóch stron. Sprawdzam teraz LOG. 22… Wygląda na to, że nic się tutaj nie załapało ale sprawdźmy jeszcze tu w tych licznikach… Forward. 0 pakietów. Czyli teraz już mogę ten Forward zmienić akcję na drop. Narazie logowanie zostawiam. Oczywiście z tym logowaniem należy ostrożnie postępować jeżeli masz… O tu jeszcze nie dałem protokołu. Jeżeli masz sytuację taką, że testowo sobie to robisz, tak jak ja tutaj nie mam żadnego środowiska obciążonego to oczywiście nie ma tu problemu, można sobie te logi pozostawiać bo ten router i tak się nudzi.

W środowisku produkcyjnym proponuję wyłączyć za każdym razem log. Logu używać tylko do debagingu czyli w momencie kiedy potrzebujesz sprawdzić co konkretnie się tutaj dzieje i wtedy dopiero ten log uruchamiać. No i zobaczymy jak to nam będzie działało. Ponownie zapinguję, teraz już mogę bez ograniczeń pingować i patrzę czy się zwiększa licznik na regule Forward Default. Widać, że się nic nie dzieje, czyli oba pingi trafiają w regułę powyżej. No dobra to reguły mam już popisane widzę, że pakiety… o, tu się Output Default coś pojawiło to sprawdzę… Co tu się wydarzyło. Czyli do loga. Output Default.

Pojawił się nowy adres multicastowy z końcówką 6. Sprawdzę… Ok no i się wyjaśnia 224.0.0.6 to jest adres, który jest używany w komunikacji Diara z pozostałymi literami. Więc ten adres też przepuszczę, czyli kolejną regułę dopiszę dla adresu multicastowego z końcówką 6. To żeby to zrobić to najpierw wchodzę do listy adresowej. Zobaczę tylko jaki opis ostatnio użyłem. Multicast Address OSFP. Tu dopiszę… i tu chodziło o adres z kocówką 5. O tu wpisałem opis. Dobra, to zmienię trochę format tej nazwy. Tak, żebym miał tutaj spójność. Ok.

No i teraz kolejna reguła… To było na output. Czyli do adresu multicastowego i accept i za chwilę jeszcze skopiuje komentarz. Kolejność… Powinna być ta reguła wyżej po prostu niż te blokujące. Zaraz tu znajdę, gdzie tu miałem tego OSPF multicast. A tutaj. Już mam oba wpisy. Tu jeszcze jestem ciekaw czy tu się nie zmieniło. Ciekawe. Nazwa się nie zmieniła. No to zmienię, tak, żeby się zgadzała, czyli z końcówką 5. Widzę tutaj teraz 224.0.0.5 i 0.0.6 Skasuje liczniki i zobaczę czy coś się jeszcze pokazuje. No i widzę, że się pokazuje 7 pakietów w Default drop na input i w forward 2.

No to idę do Loga i patrzę forward i input. Czyli tutaj muszę zdecydować co bym chciał wykonać dla tego mojego serwera Linuxowego. Jeżeli chcę, żeby on miał wyjście do internetu. Tu widać, że adresy w internecie się pojawiają, to trzeba dodatkową regułę stworzyć taką, która zezwala na wychodzące połączenia do internetu. Czyli tu mógłbym wtedy zrobić z Src 10.140.01 do dowolnego adresu. No to robimy. Forward… Tylko alias użyję… Jeżeli oczywiście zezwoliłem na ruch IP do wszystkiego od Linuxa to też ta reguła dotycząca ICMP czyli pinga również nie będzie potrzebna. Mam dwie opcje mogę je… Mogę tutaj jakby dać poniżej i ping i tak będzie wchodził jak będzie analizowany przez te reguły wyższe. Albo mogę skasować po prostu tą regułę, która idzie od Linuxa do campusu z założeniem, że wszystko od Linuxa ma być przekazywane i ma ruch przechodzić. A pingowanie tylko zgodnie z tą regułą od Campusu1 do Linuxa. No i może tak zrobię. Jak możemy sobie upraszczać to upraszczajmy.

Czyli tu jest ping, tutaj będzie wpadała cala reszta i możemy sobie zresetować liczniki i zobaczyć co tu się dalej dzieje. Jeszcze mamy na input coś do przeanalizowania. Input. Tylko tu było małą literą… To co nam się tutaj pojawia to ruch z tunelu WireGuard’a do adresu – to jest na input – do adresu multicast’owego i tu też WireGuard, adres multicast’owy i tutaj również z różnych hostów. Czyli tutaj mam WireGuarda czyli adresacja 10.255.255 a tutaj mamy adresację DMZ’u 10.140.0 i też widać, że nie idzie, nie przechodzi ruch multicastowy, czyli 224.0.0.5, to ciekawe… No to sprawdźmy.

Tą regułę, którą mamy… A.. ok. To nie przechodzi dlatego, że widać, że nie zaktualizowała się zmiana nazwy. Czyli ja muszę tu kliknąć teraz każdą z tych nazw i wybrać ten nowy alias, który stworzyłem. To dobrze wiedzieć. OSPF multicast 225. Dobrze wiedzieć. Ciekawe, w tym widoku pokazuje OSPF multicast a jak się wejdzie w bardziej szczegółowy widok, to pokazuje już nową nazwę. Dobra, to zmienię jeszcze raz na inną. Zobaczmy jak teraz. Tutaj tak samo się nie zmieniło i tu się nie zmieniło. Dobra, jedna jest już poprawa. A w drugim poprawy nie ma. Interesujące. No spodziewałbym się powiem szczerze czegoś innego tutaj w zachowaniu tego urządzenia to znaczy chyba zmienię na coś innego narazie i zmienię jeszcze raz. Chyba, że klikam nie tą pozycję, to dlatego. Spodziewałbym się, że będzie automatyczna zmiana nazwy w regułach jeżeli zmienię w liście adresowej daną nazwę a to się widać nie dzieje.

Szkoda bo wygodniej gdyby tak właśnie było. Pozycja jeszcze a. Dobrze, czyli ja źle klikałem po prostu i dlatego nie mogłem zmienić tego co chciałem. Mamy teraz już tu multicasty. Wygląda dobrze to teraz zresetuje liczniki i zobaczmy czy się pojawi coś w tych naszych regułach drop. No widać, że nie ma żadnych pakietów, które by tutaj nam wpadały w nasze domyślne reguły. W związku z tym możemy przejść do ostatniej czynności, którą dzisiaj chciałem zrobić. Czyli do eksportu tych reguł i importu na drugim urządzeniu. Żeby wyeksportować to trzeba wpisać ip/firewall/filter/export i mamy wszystkie nasze reguły wyeksportowane. Teraz mogę skopiować to po prostu.

Zalogować się do drugiego urządzenia w danej parze czyli tutaj. Teraz konfigurowałem MT1-DC-DMZ a chciałbym skopiować tą konfigurację reguł Firewall’owych tutaj na MT2-DC-DMZ. Potrzebuje też oczywiście skopiować te nazwy obiektów czy list, żeby nam to wszystko mogło zadziałać. Czyli MT2-DC-DMZ teraz. No i wchodzimy do terminala i możemy skopiować czy wkleić tutaj. Widać, że nie jest tak łatwo ponieważ nie zawsze mi prezentuje tutaj widok terminala pod prawym przyciskiem. Czyli jak na tekst najadę to mogę dać kopiuj ale już tutaj żebym mógł wkleić nie mam takiej opcji. Oczywiście nie jest to problemem. Mogę się podłączyć terminalem i zalogować się na ten adres i wtedy bez problemu wkleić ten link. No to zaraz to wykonam.

No i to samo zrobię z zasadami Firewalla. Dobra. Tu widać, że mnie odcięło od sesji ale to dlatego, że zasady tego Firewalla się nie zgadzają na drugim routerze. Więc podsumowując przekopiowałem tutaj listę z adresami na MT2-DC-DMZ reguły Firewall’owe i w tym momencie odcięło mnie od zdalnego dostępu. Dlatego, że ja szczegółowo pisałem połączenia i management, który jest związany konkretnie z tym MT1-DC-DMZ i muszę zmodyfikować to tak, żeby działało to na MT2-DC-DMZ. Nie będę tutaj już tego pokazywał bo proces jest dokładnie taki sam jak robiłem wcześniej na tym pierwszym routerze.

W związku z tym jest kwestia tylko powtórzenia tego samego schematu logowania tego ruchu, następnie wykrycia, które pakiety nie trafiają w odpowiednie reguły i pracowania nad tym, żeby to doszlifować. Dlaczego jest to istotne, żeby skopiować te reguły. No dlatego, że mamy teraz tak, że ten MT1-DC-DMZ jest masterem dla VRRP, które tutaj mamy no i na wypadek, gdyby ten MT1-DC-DMZ uległ awarii to my musimy mieć tutaj przygotowaną na tym obecnym back up’ie… musimy mieć przygotowaną odpowiednią konfigurację Firewalla, tak żeby te wszystkie pakiety, które są prawidłowe i chcemy, żeby były przekazywane zarówno tutaj od strony VAN’u, od strony lokalizacji jak i od strony tego systemu wewnętrznego Linux DC-DMZ, żeby one wszystkie pracowały prawidłowo. Czyli nawet jeżeli ulegnie awarii któryś z tych routerów to żeby funkcjonalność tej naszej sieci i dostarczanie usług nadal działały tak jak do tej pory. Dlatego trzeba taką konfigurację czy jej replikę stworzyć na MT2-DC-DMZ i dzięki temu jakby obsługiwać ten cały ruch. To co teraz mi nie działa to głównie input.

Dlatego, że odcięło mnie od zarządzania. Jeżeli chodzi o te reguły forwardujące to one będą powtarzalne dlatego, że będą zależały od source i destiation tych systemów gdzieś tutaj niżej i wyżej czyli nie będą zależały od konfiguracji interfejsów, adresów IP na MT2 więc będą kopiowane. Będzie można je spokojnie powielić.

To tyle w tym odcinku. Dziękuję Ci za uwagę. Jeżeli masz jakieś pytania to oczywiście pisz w komentarzu. Widzimy się, słyszymy już za tydzień.