Klient i serwer czasu wzorcowego w routerach MikroTik-a i nie tylko
NTP client status: Waiting

 Pomimo, że temat już poruszyłem we wcześniejszym artykule ( http://bit.sos.pl/blog/historia-sukcesu-2/mikrotik-vlan-frirewall-45 ) to sam musiałem znów stracić wiele czasu by ponownie odkryć Amerykę. Czas jest czwartym wymiarem dla fizyków. W wirtualnym świecie stawiam tezę, że pierwszym, a po nim dopiero bity adresu pakietu, które pływają po jego powierzchni lub znikają w odmętach niekończącej się przeszłości. Synchronizacja czasu jest kluczowa dla różnych zadań obliczeniowych, zależnych od znaczników czasu. Jest tak ważny, że implementacja jego obsługi odbywa się na poziomie jądra systemów operacyjnych. Z tego powodu nie powinno się tego zjawiska ignorować, a wręcz przeciwnie nauczyć się nad nim panować. NTP (Network Time Protocol) jest protokołem pracującym na porcie 123 i służy do synchronizacji czasu pomiędzy urządzeniami w sieciach strukturalnych. Uruchomienie klienta w MikrotikOS sprowadza się teoretycznie do wprowadzenia nazw serwerów czasu oraz uaktywnienie samej usługi, np.:

/system/ntp/client/set servers=tempus1.gum.gov.pl,0.pl.pool.ntp.org,1.pl.pool.ntp.org,2.pl.pool.ntp.org,3.pl.pool.ntp.org
enabled=yes mode=unicast vrf=main


lub dla wersji 6 starszego OS MikroTik (w tym przypadku też może być konieczne doinstalowanie paczki ntp) :

/system ntp client set enabled=yes primary-ntp=194.146
.251.100 secondary-ntp=83.168.69.6 mode=unicast

Diabeł tkwi w szczególe i by wybrnąć z statusu Waiting, należy dokonać przynajmniej dwóch lub trzech  wpisów w zaporze jeśli nasz dostawca internetu blokuje ruch na 123 porcie by usługa zaczęła synchronizować czas względem wzorca.

Na początku łańcucha Input w każdym razie przed drop dla chain=input wprowadzamy:

/ip firewall filter add action=accept chain=input comment=\
"Dostep WAN-ow do NTP routera MikroTika" connection-state=\
established,related dst-port=123 in-interface-list=WAN protocol=udp


Podobnie jeśli blokujemy wszystkie Output to musimy zrobić wyjątek także przed drop dla chain=output w postaci:

/ip firewall filter add action=accept chain=output comment=\
"Dostep do zewnetrznych serwerow czasu routera MikroTika" \
connection-state=established,related,new dst-port=123 out-interface-list=\
WAN protocol=udp


Jakby nadal brakowało by statusu: Synchronized musimy dodać regułę na samym początku łańcucha NAT (to jest bardzo ważne) przekierowanie portu 123 na dużo wyższy zakres, np.: 12300-12390.

/ip firewall filter add action=masquerade chain=srcnat comment="NTP fix" dst-port=123 \
out-interface-list=WAN protocol=udp to-ports=12300-12390


Osiągnęliśmy rozwiązanie synchronizacji czasu routera z wzorcowym zewnętrznym serwerem czasu, ale do pełni szczęścia brakuje nam jeszcze podzielenie się jej wynikiem z pozostałymi urządzeniami w sieci. By to uzyskać przedstawię jedną z możliwych konfiguracji kolejnej usługi czasu tym razem serwera NTP oraz serwera DHCP na tym samym routerze. Uruchomienie serwera NTP sprowadzało by się jedynie do komendy,

/system/ntp/server/set enabled=yes vrf=main


gdyby nie zapora ogniowa (firewall). Analogicznie, jak dla klienta czasu musieliśmy zrobić wyjątki w dostępie na zewnątrz to tu czynimy to dla sieci wewnętrznej  (VLAN) kolejno dla łańcucha INPUT:

/ip firewall filter add action=accept chain=input comment=\
"Dostep VLAN-ow do serwera czasu routera MikroTika" connection-state=\
established,related,new dst-port=123 in-interface=all-vlan protocol=udp


Łańcucha Output:

/ip firewall filter add action=accept chain=output comment="Dostep VLAN-ow do uslugi czasu routera\
_MikroTika dla pakietow powracajacych do VLAN-ow" connection-state=\
established,related out-interface=all-vlan protocol=udp src-port=123


O wyjątku w blokowaniu wszystkiego przez łańcuchu FORWARD dla portu 123 wcale nie zapomniałem. Ze względów bezpieczeństwa zakładam, że sieci wewnętrzne będą mogły korzystać jedynie z serwera czasu uruchomionego w bramie dającej dostęp na zewnątrz. Zakładam też, że masz serwer DHCP już funkcjonujący. Dodajemy do jego konfiguracji NETWORK serwer NTP w przykładowej sieci 10.10.90.0/24 do postaci:

/ip/dhcp-server/network/add address=10.10.90.0/24 gateway=10.10.90.1 dns-server=10.10.90.1 ntp-server=10.10.90.1


Pozostaje jeszcze przetestować konfigurację serwera czasu z poziomu stacji klienckiej. Jeśli mamy pod ręką system operacyjny Windows to proponuje wykorzystać program w32tm w postaci komendy:

w32tm /stripchart /computer:[nazwa serwera NTP lub jego IP]


Otrzymaliśmy istotne informacje świadczące o:

  • computer - dostępie klienta do serwera czasu (demon uruchomiony, konfiguracja zapory ogniowej przepuszcza pakiety na porcie 123)
  • czasie lokalnym, np. 17:46:48
  • d: drifft - o czasie podróży (tak na marginesie pisownia bez sensu, ale dla lewusów-humanistów pierdzących w stołki jak najbardziej poprawna bo mamy pułapkę dającą okazję  im zrównać z glebą istotę myślącą-twórczą :-( ) pakietu UDP z serwera do klienta
  • o: offset - różnica miedzy lokalnym czasem, a serwerem czasu
  • stripchart - wykres graficzny czasu

Idziemy krok dalej. Sprawdzamy konfigurację synchronizacji czasu lokalnej stacji roboczej komendą: 

w32tm /query /status /verbose

gdzie:

  • query - zapytanie o bieżącą konfigurację usługi
  • status - wymusza wyświetlenie stanu synchronizacji (źródło, precyzja)
  • verbose - pokazuje pozostałe szczegóły synchronizacji

Jeśli komputer nie jest w domenie to z dużym prawdopodobieństwem  otrzymamy poniższy komunikat:

The following error occurred: Usługa nie została uruchomiona. (0x80070426)

Potwierdza on, że standardowo Windows nie mają uruchomionego demona w32time, którego zadaniem jest nadzorowanie czasu systemowego. Nie pozostaje nam nic, jak uruchomić usługę komendami:

sc config w32time start=auto

net start w32time


Ponownie wykonujemy kontrolę synchronizacji czasu w Windowsie komendą:

w32tm /query /status /verbose


Zrobiliśmy krok do przodu, ale źródło czasu pochodzące z lokalnego zegara płyty głównej (CMOS Clock) pracującego na nim systemu operacyjnego to nie jest to co chcielibyśmy uzyskać w scentralizowanym  świecie. By to zmienić powinniśmy użyć poniższego rozkazu:

w32tm /config /manualpeerlist:"10.10.190.1" /syncfromflags:manual /update 


a dla stacji roboczej będącej w domenie (nie zmieniamy opcji domhier na swoją domenę):

w32tm /config /syncfromflags:domhier /update

i wymuszamy synchronizację z palca

net time /set

czy też z poziomu zasad grup (wymuszenie natychmiastowej propagacji gpupdate /force):


Otrzymamy w końcu synchronizację stacji roboczej z naszym wzorcem czasu 10.10.190.1:


CND

 Nie mniej ciekawym tematem jest uzyskanie synchronizacji czasu pod dystrybucjami Linuxa. Jest to o tyle istotne, że w większości przypadków są one bazą dla wielu usług sieciowych, które są krytyczne dla funkcjonowania firm, np. PROXMOX, SAMBA z AD i DNS oraz TrueNas, serwery WWW, baz danych POSTGRES dla systemów ERP Odoo, GRAFFITI itd. Potrafi też być niezmiernie denerwujące dla osób mających na jednym komputerze zainstalowane kilka systemów (nie mam tu na myśli wirtualnych maszyn, czy też kontenerów) w różnych strefach czasowych. Centos (RedHat) wykorzystują standardowo aplikację NTP (admini zauważyłem preferują czemuś CHRONY)  do synchronizacji czasu z zewnętrznym źródłem czasu. W tej chwili ich konfigurację pominę, a skupię się na komendach przez powłokę:

  1. timedatectl (wyświetlamy informacje o czasoprzestrzeni Linuxa)
  2. date -s "22:37:00" (ustawiamy czas ręcznie)
  3. hwclock --systohc --localtime (ustawiamy yes dla RTC in local TZ)
  4. hwclock -w (ustawiamy no dla RTC in local TZ)
  5. timedatectl set-ntp yes (ustwiamy yes dla NTP enabled)
  6. timedatectl set-local-rtc 0 (ustawiamy RTC in local TZ na no)
  7. systemctl enable ntpd; systemctl restart ntpd (ustawiamy yes dla NTP synchronizacji)
  8. ln -sf /usr/share/zoneinfo/Europe/Warsaw /etc/localtime (zmiana strefy czasowej)

Uwagi końcowe:

  1. Przy zbyt dużej różnicy w dacie, a nawet czasie ( -+5') tzw. drifft automatyczna synchronizacja może nie zadziałać i wówczas nie pozostaje nic innego, jak wstępnie ją ręcznie ustawić w stacji klienckiej.
  2. Może kogoś zdziwić, że więcej czasu poświęciłem na sprawdzenie czy działa wzorcowy serwer czasu z poziomu klienta WINDOWS niż sama konfiguracja serwera NTP. Wynika to z tego, że właściwie tylko terminale (thin clients, telefony VoIP itd.) respektują informacje dodatkowe (42 - IP NTP) jakich jest w stanie dostarczyć serwer DHCP.  Reszta systemów komputerowych nie ufa im i w konsekwencji ich konfiguracja sieciowa nie przebiega w sposób intuicyjny. Rozwiązaniem jest tu kontroler domeny, który z zasady działania jest autorytarnym źródłem informacji wzorcowych dla innych systemów z nim zintegrowanych.
  3. Wspomniałem  w drugim punkcie o kontrolerze domeny, który jest faktycznie pewnym rozwiązaniem, ale muszę być uczciwy jest to prawda przy jednorodnym środowisku. Jeśli natomiast naszym emulatorem PDC jest SAMBA to proszę pamiętać, że sam demon ntpd (NTP) nie wystarczy i musimy jeszcze uruchomić dodatkowo serwis ntp_signd (NTPSEC) lub (--enable-ntp-signd when building NTP) 
  4. Wyświetlenie konfiguracji usługi czasu w Windows odbywa się następującą  komendą: w32tm /query /configuration
  5. Wyświetlenie źródła czasu w Windows uzyskujemy przez rozkaz:  w32tm /query /source
  6.  Na koniec pozwolę sobie na parę słów teoretycznie nie w temacie. Przeszedłem płynnie od konfiguracji (zero - jedynkowej) podstawowej jednostki przepływu informacji (teza ze wstępu) do braku (jednoznaczności) zaufania. Sprzeczność sama w sobie (czarne jest białym, a białe jest czarne). Pocieszam się, że pominąwszy moje wypociny, ten sam problem spotkał ludzi mających na drugie imię Eugeniusz. Potrafiących całkować w pamięci, władających kilkoma językami, umiejących coś osiągnąć w życiu, coś zostawić dla potomnych po sobie, a jednak ich życiorysy świadczą o ciągłej walce z nim, czasem zwanym dosadniej kostuchą. Wynik tej rozgrywki znali zanim stanęli z nią w szranki, a jednak choć mieli, nie raz chwile zwątpienia, nie raz zostali oszukani to nikt ani nic nie potrafiło ich mimo wszystko zbić z raz obranej drogi. Te słowa kieruje do istot, których lewusy (mający dwie lewe ręce, jedną dłuższą drugą krótszą przystosowane do grabienia pod siebie tzw. elyty) non-stop je przegłosowują. W swojej bezmyślności nie rozumieją, że blokują nie tylko rozwój, ale również podcinają gałąź na której same siedzą. :-( By nie być gołosłownym w moim kraju jest około 40 mln ludzi, ale tylko 11 mln pracuje w firmach i na roli. Jak myślicie czy oni sobie podnoszą podatki twierdząc jednocześnie, że je zmniejszają (tzw nowy ład: z 17% tzw dochodowy wymyślony w Anglii w czasie II wojny światowej zmniejszony na 12% dochodowy, ale jednocześnie stworzona składka zdrowotna w wysokości 10% liczona jak dochodowy i bez możliwości odliczenia), czy te 30 mln? Intrygująca matematyka, gdzie 17% > 22%, która oczywiście "wynagradza" Cię za to, że jesteś produktywny, zdrowy, przedsiębiorczy itd. Tak na marginesie, czy wiecie czym się różni podatek od składki? Składka teoretycznie jest dobrowolna i ma służyć Waszemu dobru, ale w razie przerwania ciągłości wpłat  tracicie nie tylko prawo do usługi na którą łożyliście, ale również do pieniędzy już uzbieranych na kącie! Mamy wiec przykład piramidy finansowej okradającej w biały dzień ludzi. Stąd AMBER GOLD nigdy nie będzie rozliczony bo wówczas ZUS czy PZU oraz im podobne instytucje musiałby również zniknąć z rynku. Gdyby to nie było w skutkach tragiczne to chętnie bym się pośmiał z debili, których wybieramy, ale niestety w przyrodzie nic nie ginie i sami sobie wystawiamy nie tylko laurkę, ale za swoje i ich grzechy przychodzi nam zapłacić wcześniej niż później, np. wojnami. A skoro tak to krzywda nam dziać się nie może bo przecież sami tego chcieliśmy. Matematyka królowa nauk przy tej logice humanistów okazuje się funta kłaków warta. PO nas choćby POtop! 

 CBDU

Opracowane na podstawie:

 

MIKROTIK VLAN + CRS328-24P-4s+
Programowanie przełączniko-routera serii CRS3XX firmy MikroTik