Mikrotik + zewnętrzny serwer logów syslog

W tym wpisie pokażę prosty przepis jak skonfigurować serwer logów z MikroTik'iem. Z założenia chodziło o to, aby zapisywać logi ruchu sieciowego, tak jak to niby ISP ma obowiązek ;). Dlaczego na serwerze zewnętrznym? Bo to najlepszy sposób, po pierwsze MikroTik nie ma zbyt zasobnej pamięci, a po drugie to najbardziej elastyczna metoda. Raz skonfigurowany serwer logów może być później wykorzystany wielokrotnie, np. do zbierania logów również ze switcha.

Więc mamy dwa urządzenia, router MikroTik (MT) i serwer Linux. Najpierw na serwerze ustawiamy demona logów. Jak to robię na Debianie 8 (jessie) gdzie jest rsyslog. W pliku /etc/rsyslog.conf usuwamy komentarze z poniższych linii:

# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

Następnie resetujemy usługę:

systemctl restart rsyslog.service

Oczywiście trzeba się upewnić, czy port UDP 514 na naszym serwerze jest otwarty w zaporze, w przypadku systemu CentOS trzeba jeszcze włączyć ten port w SELinux.
I to by było wszystko co musimy właściwie zrobić na Linuksie, teraz przechodzimy do MT i ustawiamy zdalny serwer logów:

[admin@R2] /system logging action> print 
Flags: * - default 
 0 * name="memory" target=memory memory-lines=1000 memory-stop-on-full=no 

 1 * name="disk" target=disk disk-file-name="log" disk-lines-per-file=1000 disk-file-count=2 disk-stop-on-full=no 

 2 * name="echo" target=echo remember=yes 

 3 * name="remote" target=remote remote=0.0.0.0 remote-port=514 src-address=0.0.0.0 bsd-syslog=no syslog-time-format=bsd-syslog 
     syslog-facility=daemon syslog-severity=auto 

[admin@R2] /system logging action> set 3 remote=172.16.16.101

Następnie logi typu info przekierujemy do celu remote:

[admin@R2] > /system logging print 

Flags: X - disabled, I - invalid, * - default 

 #    TOPICS                                                       ACTION                                                      PREFIX    

 0  * info                                                         memory                                                                

 1  * error                                                        memory                                                                

 2  * warning                                                      memory                                                                

 3  * critical                                                     echo                        

[admin@R2] > /system logging set 0 action=remote 

[admin@R2] > /system logging print               

Flags: X - disabled, I - invalid, * - default 

 #    TOPICS                                                       ACTION                                                      PREFIX    

 0  * info                                                         remote                                                                

 1  * error                                                        memory                                                                

 2  * warning                                                      memory                                                                

 3  * critical                                                     echo                           

Teraz najważniejsze, ustawiamy regułę w zaporze MT, to od niej zależy stopień i intensywność logowania. Ja założyłem, iż przechwytujemy tylko ruch po protokole TCP i portach 80 i 443 (czyli http i https). Musimy również umieścić naszą regułę na początku łańcucha forward:

[admin@R2] /ip firewall filter> add chain=forward protocol=tcp dst-port=80,443 action=log disabled=no log-prefix=R2

[admin@R2] /ip firewall filter> print 

Flags: X - disabled, I - invalid, D - dynamic 

 0    chain=output action=accept log=no log-prefix="" 

 1    chain=input action=accept in-interface=ether1-gateway log=no log-prefix="" 

 2    chain=input action=accept log=no log-prefix="" 

 3    chain=forward action=accept log=no log-prefix="" 

 4    chain=input action=accept connection-state=new log=no log-prefix="" 

 5    ;;; default configuration

      chain=input action=accept protocol=icmp log=no log-prefix="" 

 6    ;;; default configuration

      chain=input action=accept connection-state=established,related log=no log-prefix="" 

 7 X  ;;; default configuration

      chain=input action=drop in-interface=ether1-gateway log=no log-prefix="" 

 8 X  ;;; default configuration

      chain=forward action=fasttrack-connection connection-state=established,related,new log=no log-prefix="" 

 9    ;;; default configuration

      chain=forward action=accept connection-state=established,related,new log=no log-prefix="" 

10    chain=forward action=accept in-interface=all-ethernet out-interface=all-ethernet log=no log-prefix="" 

11    chain=forward action=accept in-interface=ether1-gateway out-interface=ether2-master-local log=no log-prefix="" 

12    chain=forward action=accept in-interface=ether2-master-local out-interface=ether1-gateway log=no log-prefix="" 

13    ;;; default configuration

      chain=forward action=drop connection-state=invalid log=no log-prefix="" 

14 X  ;;; default configuration

      chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface=ether1-gateway log=no log-prefix="" 

15    chain=forward action=log protocol=tcp dst-port=80,443 log=no log-prefix="R2" 

[admin@R2] /ip firewall filter> move 15 destination=2

Tak wygląda reguła w najprostszej postaci, ale ma ona pewien defekt, loguje wszystko! Więc dodajemy odpowiednią opcję aby logował tylko początek połączenia (stan NEW):

[admin@R2] /ip firewall filter> set 2 connection-state=new       

[admin@R2] /ip firewall filter> print 

Flags: X - disabled, I - invalid, D - dynamic 

 0    chain=output action=accept log=no log-prefix="" 

 1    chain=input action=accept in-interface=ether1-gateway log=no log-prefix="" 

 2    chain=forward action=log connection-state=new protocol=tcp dst-port=80,443 log=no log-prefix="R2" 

...

Można jeszcze ją ulepszyć poprzez dodanie opcji limit, działa ona tak jak w iptables. Chodzi o to, że gdy mamy np. 100 połączeń na minutę do tego samego hosta to wystarczy nam tylko np. 5 z nich w logach.

Ok, czas na test, łączę się z tabletu z internetem przez MT i w systemie mam logi:

root@probook:~# tail /var/log/user.log 

Apr  2 19:37:45 172.16.16.5 firewall,info R2 forward: in:bridge_vlan20 out:ether1-gateway, src-mac 98:52:b1:79:31:94, proto TCP (SYN), 172.31.20.200:33976->216.58.209.46:443, len 60

Apr  2 19:37:46 172.16.16.5 firewall,info R2 forward: in:bridge_vlan20 out:ether1-gateway, src-mac 98:52:b1:79:31:94, proto TCP (SYN), 172.31.20.200:37422->216.58.209.42:443, len 60

Apr  2 19:37:54 probook gnome-session[1456]: (gnome-settings-daemon:1519): GLib-CRITICAL **: Source ID 2018 was not found when attempting to remove it

Apr  2 19:46:07 172.16.16.5 firewall,info R2 forward: in:bridge_vlan20 out:ether1-gateway, src-mac 98:52:b1:79:31:94, proto TCP (SYN), 172.31.20.200:43287->212.77.100.114:443, len 60

Apr  2 19:49:07 172.16.16.5 firewall,info R2 forward: in:bridge_vlan20 out:ether1-gateway, src-mac 98:52:b1:79:31:94, proto TCP (SYN), 172.31.20.200:43288->212.77.100.114:443, len 60

Apr  2 19:52:07 172.16.16.5 firewall,info R2 forward: in:bridge_vlan20 out:ether1-gateway, src-mac 98:52:b1:79:31:94, proto TCP (SYN), 172.31.20.200:43289->212.77.100.114:443, len 60

Apr  2 19:56:07 172.16.16.5 firewall,info R2 forward: in:bridge_vlan20 out:ether1-gateway, src-mac 98:52:b1:79:31:94, proto TCP (SYN), 172.31.20.200:43290->212.77.100.114:443, len 60

Apr  2 19:59:29 probook google-chrome.desktop[2048]: [2048:2079:0402/195929:ERROR:socket_stream.cc(210)] Closing stream with result -7

Apr  2 20:00:07 172.16.16.5 firewall,info R2 forward: in:bridge_vlan20 out:ether1-gateway, src-mac 98:52:b1:79:31:94, proto TCP (SYN), 172.31.20.200:43291->212.77.100.114:443, len 60

Apr  2 20:04:25 172.16.16.5 firewall,info R2 forward: in:bridge_vlan20 out:ether1-gateway, src-mac 98:52:b1:79:31:94, proto TCP (SYN), 172.31.20.200:43292->212.77.100.114:443, len 60

Logi możemy identyfikować poprzez prefix R2 jaki dodałem w regule zapory lub przez adres IP źródła. Jeżeli chcesz aby logi zapisywały są we wskazanej lokalizacji, to oczywiście możesz to zmienić[1]. R2 to oznaczenie mojego MT w moim labie a ja łączyłem się przez VLAN20, co jest zresztą w logach.

[1] http://www.rsyslog.com/storing-messages-from-a-remote-system-into-a-specific-file/

Arduino do nauki elektroniki

W sieci jest wiele tekstów i opinii na temat, czy Arduino jest dobre dla kogoś, kto chce nauczyć się elektroniki od podstaw. Oczywiście ja przedstawię tu swoją pozytywną opinię ale muszę przyznać, że w tych negatywnych też jest trochę prawdy. Wynika to z tego, iż co innego gdy ktoś bierze się za programowanie mikrokontrolera nie mając pojęcia ani o elektronice ani o programowaniu. Gdy zna się na programowaniu to jest o połowę prościej - tak mi się wydaje. Wtedy można skupić się tylko na elektronice i sprzęcie, bo "rozmawia" się przecież w ojczystym języku :) Dlatego uważam, że Arduino jest bardzo dobrym rozwiązaniem dla informatyka, ale i nie tylko.

Nagrałem nawet dwa projekty, które gdzieś tam w wolnym czasie sklepiłem na szybko. Pierwszy to nic innego jak pewnego rodzaju analogia do wyświetlacza w sprzęcie muzycznym, który wskazuje natężenie dźwięku - niestety nie miałem jak puścić tego dźwięku jednocześnie aby było go słychać.
Drugi to zdalna kontrola diodą RGB za pomocą pilota. Chciałem zrobić sterowanie TV z Arduino poprzez przechwycenie kodu mojego pilota (co mi się udało) i wysłanie go z diody IR, którą mam, ale nie znalazłem biblioteki do niej, a nie miałem czasu zagłębiać się w temat.

Teraz trochę opowiem o tym sprzęcie i jego jakiś głównych cechach. Otóż Arduino Uno Rev 3 ma mikrokontroler ATmega328p firmy Atmel, najlepiej w obudowie DIP, gdyż z takiej sam mikrokontroler można wyjąć lub wymienić go. Można również wybrać taki mikrokontroler w obudowie SMD, ale wtedy to już lepiej Arduino Leonardo. ATmega328p jest to mikrokontroler typu AVR w architekturze RISC, czyli tak jak ARM (RISC), które często mamy w telefonach i tabletach. Jeżeli mówimy o nauce elektroniki od podstaw to chyba warto wspomnieć czym właściwie różni się mikrokontroler od procesora. Najprościej wytłumaczyć to w ten sposób - jeżeli wiesz, że komputer składa się z wielu podzespołów złożonych razem takich jak CPU, RAM, HDD, Mainboard, to mikrokontroler jest tym wszystkim w jednym kawałku krzemu. Oczywiście wtedy jego komponenty mają inny charakter, jak np. dysk twardy, wtedy to jest pewna odmiana pamięci flash i dlatego taki mikrokontroler różni się sposobem połączenia tych wszystkich elementów, co zwie się architekturą. Taki mikrokontroler ma w sobie zintegrowany CPU ale nie ma on takich wydajności jak typowe procesory choćby w laptopach. Dokładnie to we wspomnianym modelu jest to 20 MHz.

Warto również poruszyć temat programatora, bo Arduino samo w sobie, tak naprawdę jest "płytką prototypową" jak to jego producenci określają. A co należy rozumieć przez płytkę prototypową? A no, to nic innego jak płytka z zintegrowanym mikrokontrolerem (tym zajmuje się drugi mikrokontroler do USB na płytce w obudowie SDM) i niezbędnym obwodem do pracy głównego mikrokontrolera. Gdyby nie to, to potrzebowałbyś oddzielnego mikrokontrolera i oddzielnego obwodu z głównym mikrokontrolerem, co wyglądałoby jak kupa kabli i nie byłoby tak wygodne jak gotowa elegancka płytka. W sieci znajdziecie wiele poradników jak złożyć samemu taką płytkę na płytce stykowej jeżeli kogoś to interesuje tak jak mnie interesowało :).

Na rynku dostępnych jest wiele podobnych rozwiązań, zwłaszcza osoby interesujące się systemem GNU/Linux powinny kojarzyć projekt Raspberry Pi. Więc czym różni się Arduino od Raspberry Pi? Podstawowa różnica to możliwości mikrokontrolera, o ile można go tak nazwać. Z założenia nim jest, ale nie wszystko ma zintegrowane w środku, potrafi korzystać z zewnętrznych kości pamięci ale ogólnie jest zintegrowany. Za możliwościami idzie oprogramowanie, w Arduino jest relatywnie prosty procesor, więc i do nauki jest w sam raz. Z kolei w Raspberry Pi procesor umożliwia już uruchamianie zaawansowanych systemów wielozadaniowych (tak tak to GNU/Linux) i jednocześnie oferuje jeszcze piny I/O ale nie są one już dostępne bezpośrednio jak w Arduino. W Raspberry Pi pinami I/O sterujemy za pomocą odpowiedniej biblioteki, najczęściej w Pythonie. jeżeli nie wyraziłem się dość jasno to polecam obejrzeć to wideo. Więc dla mnie jako weterana z GNU/Linux generowanie sygnałów 5V z systemu Linux za pomocą skryptów Pythona to mało pouczające, zwłaszcza dla takiej osoby. Ponadto gdy weźmie się cenę Raspberry Pi to tym bardziej się nie opłaca.

Powiem słów parę jeszcze o modułach do Arduino, które są sprzedawane wraz z nim lub osobno. Cóż większość z nich jest drugiej jakości, dla przykładu taki czujnik dźwięku, który testowałem jest tak czuły, iż odróżnia chyba tylko dwa stany natężenia dźwięku: wybuch bomby z 1 i 10 metrów :) Chociaż do zrobienia czegoś takiego może i by się nadał :) No ale skoro ma być tanio to i tak nie taki zły kompromis, ponieważ nauczysz się jak działają takie urządzenia, a czujnik zawsze można kupić lepszy jeżeli będzie potrzebny. Oczywiście nie wszystkie moduły są takie lipne, są też i dobre.

Ostatnią rzeczą jaką chcę nadmienić, jest to, że Arduino ma przeważnie gotowe biblioteki do wielu modułów. Nie zawsze ale i tak to jest lepsze niż to, z czym ja miałem do czynienia na studiach, czyli płytką Texas Instruments, z którą aby cokolwiek zrobić trzeba było ustawić dziesięć flag. Oczywiście, gdyby zabrać z Arduino biblioteki to tu również będzie taka sytuacja, ale nie jest.

Wypada jeszcze dodać, że w pewnym sensie Arduino i temu podobne są przygrywką do tzw. IoT, czyli Interentu rzeczy. Zapewne słyszałeś już o inteligentnych domach, który zapala światło gdy przychodzisz, spuszcza wodę gdy wychodzisz ;) To wszystko jest realizowane na bazie małych minikomputerów do których podłączona jest masa czujników i przełączników. Oczywiście inteligentne domy to tylko przykład, ja podam swój, który mnie bardziej interesuje. Chodzi o moduł Arduino Ethernet Shield, który również sobie zakupiłem i możliwość monitorowania parametrów np.... Na przykład w szafce sieciowej, gdzie w lato może być naprawdę gorąco możemy wsadzić Arduino, które będzie za pomocą czujnika temperatury sprawdzać czy nie jest za gorąco i odpowiednio włączać jakieś urządzenie chłodzące poprzez przełącznik 230V. Bardzo prosty projekt do wykonania i bardzo przydatny. Można go również zlutować na stałe gdy konstrukcja się sprawdzi i urządzenie gotowe.

Na koniec jako inspirację podsunę projekt, który również można wykonać z Arduino, a jest nim LED Cube.

Rozbudowa sieciowego lab-u

Ostatnimi czasy postanowiłem rozbudować mój domowy lab, który opisywałem już wcześniej w poście Domowy lab Cisco + MikroTik. W tamtym poście skupiłem się głównie na sprzęcie Cisco, ponieważ wtedy to właśnie z niego składał się mój domowy lab, ale wspominałem również o nowym tanim modelu MikroTik-a hAP lite. Tym razem poszedłem w stronę zakupu routerów MikrotTik, dokupiłem ich parę. Niestety (tak mi się wydawało na początku) teraz nie można już kupić hAP lite w leżącej obudowie, cóż zmienili design ale ta stojąca jest dobra i wcale się nie przewraca jak powpinamy wszystkie kable - pięknie stoi i prezentuje się. Warto byłoby napisać o tym jak wygląda taki MikroTik w środku, co ciekawe w leżącej obudowie jest inny chip niż w stojące, ale to różnica głównie producencka, bo architektura jest ta sama. Jako ciekawostkę mogę podać, iż w środku znajduje się tylko jeden chip, który robi za WiFi, Ethernet, Switching, USB, te ostatnie obsługiwane jest tylko jako zasilanie. Jednym słowem jest to bardzo lekka konstrukcja, dlatego jest zasilana przez port USB 5V, a wszystkie razem w moim labie pobierają 7.5W. Oczywiście ich procesory mają odpowiednio mniejszą moc, ale coś za coś. Odpaliłem je nawet z power banku.
Połączenie routerów MikroTik i switch-ów Cisco to piękne rozwiązanie. MikroTik daje Ci routing i wireless, zresztą wystarczy spojrzeć na stronę certyfikacyjną. Tak tak, MikroTik od jakiegoś czasu uruchomił fajny program certyfikacyjny z mapką gdzie najbliżej znajdziesz specjalistę do urządzeń MikroTik.
Więc teraz w swoim labie mam piękny routing, również z Cisco (switch 3550), wireless (czyli AP-ki MikroTik, które mają full opcji dla WiFi) oraz switching na Cisco. A teraz pochwale się jak pięknie wygląda mój lab.

A teraz przedstawię schemat sieci jaki zbudowałem.

Tu należy się trochę wyjaśnień, zresztą i tak chciałem poruszyć temat tego jak fajnie można wykorzystać przemądre switche Cisco Catalist 3550. Zauważ, iż wewnątrz siatki routerów (przeważnie kable czerwone) użyłem prawdziwych publicznych adresów IP, co wyraźnie odróżnia je jako routing WAN. Oczywiście na tej samej linii może być i WAN i LAN. Ale skupmy się na niebieskich przerywanych liniach, to LAN, sieci brzegowe. Tam użyłem adresacji prywatnej, ale połączone jest to z WiFi za pomocą VLAN-ów. Otóż od routera R1, R2 i R3 idzie kabel do jednego 3550, ale jest to tak skonfigurowane, jakby były to fizycznie inne switche w innej lokalizacji. W 3550 możemy robić porty tylko w L3 (routing), L2+L3 (VLAN + IP), oraz tylko L2 (VLAN bez IP) i tą ostatnią opcje zastosowałem. Dzięki temu iż te VLAN-y nie mają IP to nie mogą komunikować się z całym routingiem, który jednocześnie jest uruchomiony wewnątrz 3550. Gdybym ustalił adres IP dla tych VLAN-ów i włączył routing, to okazałoby się iż np. sieć 10.4.24.0/24 ma bezpośrednie połączenie z 22.22.22.254, a tak to wszystkie połączone urządzenia do tej sieci, czy to przez kabel za pomocą portów w 3550, czy przez WiFi do sieci 22.22.22.254 muszą przebyć drogę przez routing WAN. Podsumowując, tam gdzie są niebieskie przerywane linie, można na tym schemacie wstawić oddzielne switch za routerem i efekt będzie taki sam.

Domowy lab Cisco + MikroTik

Ostatnio w pracy miałem sytuację, gdzie dość wymyślna konfiguracja MikroTik'a w roli podwójnego AP'eka nie chciała działać po LVAN'ach z zarządzalnym switchem D-Link. Problem w tym, że cała rzecz miała miejsce z lokalizacji w której nie przebywam na co dzień, lecz tylko zachodzę w razie potrzeby. Dwie lub trzy takie nieudane wizyty skłoniły mnie do rozmyśleń nad wyposażenie się we własny sprzęt zarządzalny w domu, gdzie mógłbym na spokojnie odtworzyć daną infrastrukturę (srv Linux -> zarządzalny przełącznik -> AP MikroTik) i konfigurację VLAN-ów. Więc rozpocząłem szukanie sprzętu i tak zakupiłem dwa przełączniki Cisco. Przetestowałem konfigurację MikroTik'a i o dziwo okazało się że jednak jest prawidłowa. Szukałem więc problemu w przełączniku i okazało się że port do którego podłączałem MikroTik'a został zablokowany przez protokół STP. Trochę czasu zajęło mi odkrycie tego bo musiałem przejrzeć wspaniały GUI D-Linka. Widocznie podczas testowania konfiguracji MikroTik'a z kilkoma mostami zrobiłem pętle, a potem było już coraz gorzej, bo co bym nie robił to port był już zablokowany.

Jaki jest morał tej historii? A no następujący, jeżeli chcesz zaoszczędzić sobie stresu i frustracji z niedziałającą konfiguracją, która powinna zadziałać za pierwszym podejściem to warto zainwestować we własny sprzęt. Owszem, mogłem nie wydawać tych pieniędzy i od biedy zrobić sobie takiego testowego laba w pracy, miałem nawet do tego przełączniki zarządzalne TP-Link ale co własny biznes to własny ;) W pracy nie zawsze jest wystarczająca ilość czasu na to, po za tym, sprawdzenie tego w domu na spokojnie jest o wiele bardziej komfortowym rozwiązaniem i stwarza o wiele większe możliwości. Teraz opiszę trochę jaki sprzęt zakupiłem, po co i dlaczego ten oraz o czym warto wiedzieć przed zakupem aby się nie rozczarować.

Zanim przejdę do szczegółów uprzedzę tylko czytelnika, aby zwrócił uwagę na datę tego wpisu gdyż od tej zależą ceny opisywanego sprzętu. Więc, na początku myślałem, że potrzebuje właściwie tylko zarządzalnego przełącznika. W sumie nie musi być to wielkie coś aby obsługiwał tylko VLAN-y, STP i kilka innych mechanizmów typowych dla przełącznika. Właściwie to nawet nie myślałem o Cisco ale... Po przejrzeniu ofert starego sprzętu na allegro okazało się, że przełącznik np. D-Link z funkcjami które wymieniłem wcale nie kosztuje taniej niż Cisco, wręcz więcej. Prawda, że te przełączniki innych firm są zazwyczaj nowsze niż niemal archaiczne Cisco ale nawet te archaiczne Cisco potrafi więcej niż obecne D-Link-i. A że Cisco wcale nie jest mi zupełnie obce - kiedyś chodziłem na kurs Cisco - to dlaczego nie. Więc trochę poszukałem jaki model wybrać i miałem kupić catalyst 2950, który miał praktycznie wszystko co powinien mieć przełącznik, a jego koszt to ok 100 zł z przesyłką włącznie. Trzeba przyznać, że to nie jest wielka cena, a że przesyłka kosztuje prawie 20 zł i trochę się napaliłem na ten sprzęt to zacząłem zastanawiać się czy nie dobrać drugiego do pary (na jednym np. STP nie potestujesz). Więc chciałem kupić jeszcze jeden, ale nie koniecznie taki sam, bo nie wiele więcej się na nim nauczę - praktycznie sprowadziłoby się to do wpisywania tych samych komend na dwóch a nie jednym urządzeniu - no prawie ;). Szukałem czegoś co byłoby do pary z c2950 i jednocześnie będzie zupełnie czymś nowym. Zdecydowałem się na catalyst 3550, przełącznik pracujący zarówno w warstwie drugiej i trzeciej (L2, L3), czyli jest to router-switch. Oczywiście odpowiednio kosztuje, ok. 200 zł. Na pocieszenie powiem, że z archiwum forum ccie.pl wynika, że 6-7 lat temu trzeba było za niego zapłacić ok. 1000 zł dla zabawy, lol.

No więc zamówiłem c2950 i c3550, co kosztowało mnie ok. 300 zł. Przyszły, pierwsze wrażenie z 2950 to ładny, mały i do rzeczy, nie za wiele ciągnie, jak dobrze pamiętam to ok 40W. Natomiast drugi 3550 trochę mnie rozczarował, wielkie ciężkie pudło (jego płaszczyzna to chyba 0.5 m2), które chodzi prawie jak odkurzacz i ciągnie 80W - pięknie - nie wspominając o tym, że jego L2 nie konfiguruje się go tak samo jak 2950. Ma on wiele więcej mechanizmów i z tego wynikają te komplikacje. Oczywiście warto wspomnieć, że ma on również więcej możliwości :). Dla przykładu 2950 może mieć wiele VLAN-ów ale tylko jeden może mieć adres IP, 3550 może mieć wiele VLAN-ów i każdy z nich może mieć własny adres IP, a między nimi oferowany jest routing. Skoro już wydałem na niego 200 zł to nie odpuściłem mu i zabrałem się za przetestowanie jego routingu. Z tego co czytałem to zapowiadało się ciekawi, ale pierwszy kubeł zimnej wody na głowę mój 3550 wylał mi już minutę po tym jak włączałem na nim ten routing. Otóż podłączyłem go do mojego Linksysa (domowego routera) i chciałem zrobić router za routerem. Okazuje się, że pięknie działa i tak minutę, po minucie również pięknie przestaje działać :). Pierwsza myśl jaka przyszła mi do głowy, to to że kupiłem jakiś złom, który wbrew zapewnieniom sprzedawcy nie jest wcale w 100% sprawny. Podzieliłem się tym problemem na forum ccie.pl i po ok. tygodniu dyskusji i testowania rozwiązaniem okazało się upgrade systemu - lol działa :). Chodzi dokładnie o to, że te starocie nie chce normalnie gadać z niektórymi nowymi sprzętami, a konkretnie małymi routerami, z PC zawsze działa. Zdawało mi się, że port Ethernet to port Ethernet, cóż.

Tak się ucieszyłem, że w końcu zaczął działać, że dokupiłem sobie MikroTik'a. Tak się złożyło, że niedawno MikroTik wydał nową serię zwaną hAP Lite, i co jest w niej takiego fantastycznego? A no to, że można go kupić za 100 zł (mówimy o nowym sprzęcie). Szczerze mówiąc to już wcześniej chciałem sobie kupić MikroTik'a, zwłaszcza gdy pojawił się ten model, bo w takiej cenie to urządzenie nie ma konkurencji patrząc na możliwości. I tak zaczynając do switchingu doszedłem do routingu w domowym labie. A że zabawa z protokołami dynamicznymi wymaga pewnej ilość routerów, a ja byłem już po zabawie ze swoim c3550 w routing statyczny to postanowiłem dokupić jeszcze jeden przełącznik tego typu. I tak wielki i mądry przełącznik Cisco 3550, który nie zrobił na mnie dobrego wrażenia na samym początku stał się moim ulubieńce po bliższym zapoznaniu. Reasumując zakupiłem następujący sprzęt Cisco: 1x c2950 i 2x c3550, co daje trzy przełączniki i dwa routery. W sumie na wszystko wydałem 700 zł w tym książka do routingu Cisco Press, która też kosztuje prawie stówę.

Tak czy inaczej przy obecnej ilości sprzętu uzyskałem poniższy schemat sieci.

Warto zauważyć, że jak połączę laptop, który będzie pracował jak router Linux z 3550 kablem to otrzymam dość ładną siatkę. Oczywiście posiadam jeszcze inne komputery więc kombinacji jest wiele.

Trzy przełączniki to optymalna ilość do testowania switchingu, z kolei fakt, że dwa z nich mogą być również routerami pozwala potestować również mały routing. Dlaczego wybrałem kolejny przełącznik (3550) zamiast oddzielnego routera Cisco. A no dlatego, że po pierwsze router Cisco kosztuje nawet więcej niż 3550, a jak wiadomo jeden router to i tak za mało. Po za tym w takim przełączniku jest wiele portów i z każdego z nich możesz zrobić port routera, natomiast w standardowych routerach Cisco nie wiele jest portów Ethernet, no chyba, że dokupimy kolejne moduły. Routery można symulować w GNS, po za tym w roli routera bardziej interesuje mnie system Linux, przełączniki to co innego. I tu zahaczam o temat symulatorów i emulatorów. Często można spotkać się w internecie z opinią, że nie trzeba nić kupować bo wszystko można mieć na wirtualnym środowisku, takim jak np. Cisco Packet Tracer lub GNS3. Hy, tak ale spójrzmy na to z praktycznego punktu widzenia - dobrym przykładem jest wspomniana historia, która mi się przydarzyła. W mieszanym środowisku, gdzie mamy wiele urządzeń różnych producentów konfiguracja wcale nie jest taka prosta, tu czasami rozchodzi się o to, czy dana para urządzeń w ogóle będzie ze sobą współpracować tak jak tego oczekujemy. Wiele osób zdawało certyfikat CCNA, a nawet CCNP i bez laba w domu, prawda, ale na egzaminie Cisco są urządzenia tylko Cisco więc można i ćwiczyć na Packet Tracer. Warto jednak zauważyć, że na samym kursie Cisco ćwiczenia wykonuje się na prawdziwym sprzęcie, a to jaka jest jego dostępność dla słuchacza jak to było w moim przypadku to już inna sprawa. Z kolei GNS3 nie wspiera wszystkich modeli, a switchy podobno nie emuluje. Tak więc GNS3 pewnie wykorzystam do testowania routingu ale kombinacji Linux + Switch + MikroTik to on nie zastąpi pomimo, iż wiem że da się emulować MikroTik'a. Ponad to różnego rodzaju symulatory wcale nie są idealne do nauki. Sam używam wirtualnych systemów Linux, niemal zawsze to robię gdy chce coś przetestować ale nie chcę mieszać w swoim systemie. Tylko, że to jest doskonały sposób dla osób, które doskonale znają dane rozwiązanie, a wirtualizacji używają tylko dla wygody. Sam pamiętam jak kiedyś uczyłem się serwerów Linux na starym serwerze IBM, który zakupiłem na allegro za 200 zł. Dziś wirtualizacja dla systemu Linux jest tak rozwinięta, że nikomu bym tego nie polecał, ale warto zaznaczyć, że dziś wirtualizacja systemów jest na innym poziomie niż emulacja sprzętu Cisco na GNS i ma nieco inny cel. Tak więc uważam, że jeżeli ktoś ma zamiar testować różne konfiguracja z różnymi producentami to jednak lepszy jest fizyczny sprzęt, a symulatory są dobre jak wiemy doskonale co robimy, ale chcemy to przetestować w innej skali.

Napisałem już co moim zdaniem jest fajnego w posiadaniu laboratorium sieciowego w domu, a teraz czas na to co w tym jest nie fajnego i na co należy uważać. Po pierwsze to wspomniane przełączniki są starociami, 3550 jest z roku 2004 a 2950 jeszcze wcześniej. Po drugie zajmują mnóstwo miejsca i pięknie huczą. Po trzecie są sprzedawane bez okablowanie, o ile kabel zasilający to nie wielki problem to kabel konsolowy będzie trzeba sobie dokupić bo inaczej nawet do nich się nie dostaniemy. Ja musiałem sobie jeszcze dokupić adapter RS-232 (port szeregowy) do USB, aby móc podłączać je do mojego laptopa. Kolejną sprawą jest to, że te urządzenia jeszcze nie wspierają auto-negocjacji (Auto-MDI/MDI-X) co skutkuje koniecznością łączenia tych urządzeń za pomocą kabli krosowanych. Na koniec podam jeszcze dobrą informację, przełączniki 3550 są sprzedawane z dwoma wersjami oprogramowania, SMI, która nie zawiera wszystkich dynamicznych protokołów routingu i EMI, która je zawiera. Przełącznik z licencją na wersję EMI są dwa razy droższe, ale te tańsze nie robią problemów podczas aktualizacji do EMI ;)

Czy warto było kupić te złomy aby się czegoś pouczyć? Warto!

Microsoft na GitHub - czyli przyszła koza do woza

Mikrosoft z miłości do open source ;)

Ostatnio pracowałem nad artykułem na temat projektu Docker. W tamtym czasie wiadomo było jedynie, że Microsoft zamierza wdrożyć technologie Docker do swojej najnowszej wersji systemu Windows Server, nie było jednak wiadomo, czy chodzi tylko o klienta czy również o demona twz. Docker Engine. Dziś już wiadomo, że Microsoft przeportował kod projektu Docker na swój system, a kod umieścił na GitHub. Tak więc Microsoft ma natywnego Dockera. Przyznam się szczerze, że nie śledzę nowości związanych z Microsoft Windows, chyba że ma to coś wspólnego z systemem Linux jak tym razem.

Podczas oglądania prezentacji "Windows Containers: What, Why and How" popadłem w dość znaczne zdziwienie. Oglądając to co prezentują, i co ważniejsze w jaki sposób o tym mówią, pomyślałem sobie "oni wszystko ściągają z GNU/Linux i jeszcze na dodatek udają że to ich inicjatywa". Prezentacje Dockera na ich systemie zaczynają od tego, że jest to ich technologia i nazywa się Windows Server Containers, słowo Docker pada tylko wtedy gdy musi - podczas odpalenia dema i omawiania poleceń, które należy wpisać (polecenia nazywa się "docker").



Moja ocena tej prezentacji jest następująca. Microsoft goni GNU/Linux i Open Source. Starsi linuksiarze pamiętają co o otwartych technologiach i systemie Linux mówił założycie Microsoft. Dziś Microsoft jest na GitHub, który to jest hostingiem systemu rozwijania oprogramowania Git stworzonym przez Linusa Torvaldsa. Co za ironia losu.

Mało tego, Microsoft stworzył .NET na system Linux również w natywny sposób, jak sam tłumaczy na prezentacji "Taking .NET Cross-Platform: Building .NET Applications on Linux and Mac" głównym powodem jest to, iż obecnie rozwój nowych technologi odbywa się na otwartej platformie Linux. Wydaje się, że Mikrosoft już poją że walkę na systemy serwerowe już przegrał, ostatnią przewagą jaką mu zostało jest oprogramowanie. Mikrosoft woli się otworzyć i nakłaniać deweloperów w ten sposób do wyboru ich technologi, póki jeszcze większość oprogramowania użytkowego jest zaimplementowana główne na platformę Windows. Pojęli, że jak poczekają jeszcze dekadę to oprogramowanie zostałoby przepisane na otwarte platformy, a wtedy Mikrosoft zszedłby do roli naprawdę "mikro" oprogramowania.



Kolejną ciekawostką jest to, iż Mikrosoft ma zamiar wprowadzić natywną obsługę SSH do swojego systemu, rewelacja! Tymczasem jest rok 2015. Wygląda na to, iż pojęli to, że w wielu zadaniach interfejs CLI jest efektywniejszy, dlatego już jakiś czas temu wprowadzili PowerShell. Swoją drogą jego stworzenie to kolejny dowód na to, że kopiują sprawdzone rozwiązania z GNU/Linux, który jest na czele rozwiązań Cloud. Jak wspomniałem Mikrosoft ich goni, ale to już nie ta pozycja co 10-15 lat temu. Poza tym przyglądając się prezentacji kontenerów w Windows Server to owszem, przenieśli Dockera, ale Linux oferuje wiele więcej z tym związanych mechanizmów, chociażby to nad czym teraz RedHat tak intensywnie pracuje, czyli wsparcie SELinux dla kontenerów. Swoją drogą jestem ciekaw jakie rozwiązania zastosowali w swoim systemie, które spełniają te same funkcje co cgroups i namespaces w jądrze systemu Linux. Poza tym, to czym Mikrosoft się teraz fascynuje użytkownicy GNU/Linux już dawno wdrożyli w swoich serwerowniach. Puenta jest oczywista, Mikrosoft uczy się od GNU/Linux i próbuje naśladować, to też dobra informacja ;)

Na koniec wspomnę jakie pytania padły po prezentacji kontenerów z publiczności:

• "Czy wspierają domeny?" - No tak, cała filozofia Mikrosoftu, teraz ich obsesja domen nie współgra z koncepcją kontenerów Docker z prostego powodu - to zupełnie dwa różne światy.
• "Co z licencjami?" - Haa, i wszyscy w śmiech wraz z prowadzącym. Wiadomo, że licencje w Mikrosoft są kuriozalne, a tu można tworzyć bardzo wiele i bardzo szybko, a co z haraczem?
• "Co z ochrono przed wirusami?" - Yyy, zapomniałem, oni się bez nich nigdzie nie ruszają ;) Spokojnie Twój antywirus będzie szukał wirusów również wewnątrz kontenerów, także idź się pobawić tylko nie wychodź poza domenę ;)

https://github.com/Microsoft/docker

Re: "Na cztery anteny"

Internet jest zadziwiającym medium informacji. Jeszcze nigdy dostęp do informacji nie był tak prosty. To zadziwiające, że siedząc wygodnie w domu mogę zapoznać się z wynikami opracowań, które przeprowadzono w jednej z najlepszych uczelni na świecie. Tak więc sam dostęp do informacji nie jest dziś problemem, ale czy to znaczy, że potrzeba już tylko chęci do nauki? Hyy, tak, chociaż jest jedno "ale", o którym chciałbym wspomnieć.

Otóż łatwość i otwartość z jaką można umieszczać informacje w internecie (czego oczywiście nie krytykuje) powoduje pewien efekt uboczny zwany - jakością informacji. Ostatnio coraz częściej tego doświadczam. Tytuł tego wpisu nawiązuje do artykułu z PC Format 12/2014, który znalazłem na ich stronie. Moim celem nie jest robienie obciachu dla tej gazety, lecz dementowanie niekompletnych informacji, które tworzą fałszywe diagnozy. Otóż wspomniany artykuł opisuje nowy router WiFi, a dokładnie Nighthawk X4 AC2350 WiFi Router model R7500 firmy NETGEAR, który to podobno jest pierwszym routerem obsługującym nowy standard 802.11ac, co niestety również prawdą nie jest :(.

Przejdźmy jednak do danych technicznych i sposobu przeprowadzenia testu. Otóż jedno i drugie jest nijakie. Nawet na stronie producenta dane techniczne nie zawierają wszystkich szczegółów, które decydują o możliwych do osiągnięcia prędkości. Za to pełno jest tam danych marketingowych. Z kolei prezentowanie wyników testów prędkości z użyciem routera WiFi z czterema antenkami i nie wspomnienie przy tym ile anten ma nasz klient jest totalnym nieporozumieniem. Z całego artykułu najbardziej zapamiętałem to, iż urządzenie to wyglądem przypomina gadżet z gier komputerowych i kosztuje ponad 1000 zł, co jest totalną porażką. Nawet sam autor stwierdził:

"Mimo tak silnej specyfikacji router wcale nie okazał się najszybszym z testowanych przez nas urządzeń – przepustowość była nawet o połowę niższa niż najszybszych routerów."

No właśnie, ciekawe tylko dlaczego :) W tym artykule zabrakło mi odpowiedzi na to pytanie, więc postanowiłem sam o tym napisać. O wspomnianym routerze możemy przeczytać:

"Ma pięć interfejsów gigabit ethernet, interfejs Wi-Fi pracujący w pasmie 2,4 GHz (z przepustowością do 600 Mb/s), a także w pasmie 5 GHz (cztery kanały o teoretycznej łącznej przepustowości 1733 Mb/s)."

Natomiast autor osiągną 79 Mbit/s w standardzie 802.11n 2.4 GHz i 251 Mbit/s w 802.11ac 5 GHz.
Niestety nie wiemy jaka była szerokość kanału, jaki GI ani QAM, ale z przedstawionych danych wnioskuje, że autor miał laptopa z jedną anteną i przeprowadzał testy w zaśmieconej przestrzeni, co wydaje się dziwne, gdy mowa o częstotliwości 5 GHz, ale z drugiej strony skoro miał taką antenę w laptopie to i pewnie nadajnik też miał.

Do pierwszego wyniku (79 Mbit/s) pasuje kanał 40 MHz, GI 800 ns, 16-QAM i kodowanie 3/4, oczywiście w konfiguracji anten 1x1. Wniosek z tego taki że 2.4 GHz jest bardziej zaśmiecony, lub zła/brak konfiguracji kanałów.
Do drugiego wyniku w standardzie 802.11ac (251 Mbit/s) pasuje kanał 80 MHz, GI 400 ns, 64-QAM i kodowanie 2/3, również w konfiguracji anten 1x1.

Więc, jaki jest sens przedstawiania urządzenia z czterema antenami, jeżeli posiadamy klienta tylko z jedną, no chyba że zrobiono by to z czterema takimi klientami. Aby użyć MIMO 4x4 to trzeba mieć w kliencie kartę z czterema antenami, nie wiem czy takie w ogóle się praktykuje na rynku. Natomiast test z użyciem wielu klientów byłby jak najbardziej na miejscu w sensie pojemnościowym, gdyż i tak każdy z nich nie osiągną by więcej niż 433 Mbit/s w teorii. A na pewno nie osiągnęliby tyle wszyscy czterej na raz, gdyż ta puszka ma tylko interfejs LAN 1 Gbit/s :) Nawet gdyby pobierać dane z dysku podłączonego do tej puszki, to i tak na moje oko nie wyciągnęłoby się więcej niż ok. 640 Mbit/s. Dlaczego? Prędkość odczytu dysku przenośnego.

Na koniec wspomnę słów parę o zapisie stosowanym przez producenta, który podaje przepustowość jako "600 + 1733 Mbps" i wychodzi mu 2.33 Gbps. Hehe powiem tak, takie stwierdzenia osiąga się następującą metodą: znajdźmy dwie największe liczby i jeszcze je zsumujmy, będzie dużo :). Teoretycznie, można by go uruchomić jako AP w dwóch standardach i pasmach 2.4 i 5 GHz, ale co z tego jak po pierwsze nawet połowa tej sumy nie przejdzie przez kabel, z którego ta puszka za tysiaka bierze internet/sieć, a po drugie są to prędkości warstwy fizycznej, do aplikacji dochodzi może jakieś 70% tego, reszta zużywana jest na organizacje ruchu - czyli protokoły sieciowe służące do transportu.

Jeżeli ktoś zapytałby się mnie, czy warto kupić taki router WiFi, to odpowiedziałby mu chyba na głowę upadłeś :) No chyba, że chcesz zapłacić za cztery a używać jednej - parafrazując do tytułu ;)

DIME - w obronie prywatności

W ostatniej dekadzie amerykanie stracili części swojej prywatność na rzecz bezpieczeństwa, z czym nie wszyscy do końca zdołali się pogodzić. Jedną z takich osób jest Ladar Levison. W 2013 roku został on zmuszony przez władze U.S. do zamknięcia swojego biznesu, który rozwijał przez 10 lat. Jego firma Lavabit oferowała hosting dla usługi szyfrowanej poczty, która zapewniała prywatność jej użytkownikom. Głównym powodem zamknięcia Lavabit było to, że z jej usług korzystał Edward Snowden’s, w wyniku czego nawet FBI było bezradne. Otóż poczta była zaszyfrowana w taki sposób, że nawet administrator serwisu (Ladar Levison) nie mógł jej podejrzeć bez znajomości odpowiedniego hasła ustalanego przez użytkownika skrzynki.

Ladar Levison zaprzestał hostowania szyfrowanej poczty pod naciskami władz i nowego prawa, ale nie porzucił marzeń o wolności i prywatności użytkowników poczty elektronicznej. Niedługo po tych wydarzeniach utworzył nowy projekt o nazwie Dark Mail, który był kontynuacją rozwoju usługi szyfrowanej poczty jako projektu open source, którą wcześniej oferowała jego firma. Na konferencji DEF CON 22 Levison zaprezentował nowości w projekcie Dark Mail i ogłosił jego nową nazwę Dark Internet Mail Environment (DIME), która ma oznaczać nową bezpieczną architekturę poczty.

Levison chce, aby DIME stał się domyślnym standardem poczty. Trwają prace nad opracowaniem standardu w formie dokumentów RFC. Obecnie nie można nazwać projektu standardem, ale raczej prototypem, a jego rozwój dopiero się rozpoczyna. Ponieważ DIME to nie tylko serwer ale i klient poczty, więc przed autorami jeszcze dużo pracy, dlatego Levison zachęca do współpracy. Obecny klient poczty dla DIME to Volcano, który jest forkiem Thunderbirda, natomiast serwerem jest fork serwera magma używanego wcześniej przez firmę Lavebit. Większość kodu jest dostępna na GitHub Lavabit.

Zanim przejdziemy do omówienia architektury i zasady działania DIME warto wspomnieć na czym polega zasadnicza różnica, pomiędzy pocztą elektroniczną a innymi usługami. Otóż obecnie króluje architektura klient-server, jest tak w przypadku HTTP, FTP, czy DNS. Poczta natomiast w uproszczonym ujęciu działa w architekturze server-server. Jest to chyba jedyna usługa, która do prawidłowego działania wymaga zgodnej konfiguracji dwóch niezależnych serwerów. Innymi słowy mówiąc, nie można wysłać e-maila za pomocą DIME, jeżeli jego odbiorca również nie posiada konta na serwerze obsługującym taką architekture. Poza tym, taki e-mail może przejść przez więcej niż dwa serwery zanim trafi do serwera odbiorcy.

Nie bez znaczenia jest sama architektura serwerów poczty, które implementują kilka protokołów. I tak na przykład do wysłania przeciętnego e-maila zostaną użyte następujące protokoły: SMTP -> SMTP -> POP3/IMAP. Ponieważ jest to dość złożony model, to serwery poczty posiadają modułową budowę, pomijając fakt, że zazwyczaj serwer poczty wychodzącej i przychodzącej to dwa oddzielne serwery (demony). Z grubsza możemy wyróżnić trzech najważniejszych agentów. Mail User Agent (MUA) zajmuje się obsługą swojego użytkownika, ma tu miejsce komunikacja klienta poczty z serwerem poczty. Mail Transport Agent (MTA) zajmuje się transportem listów pomiędzy serwerami nadawcy i odbiorcy. Mail Delivery Agent (MDA) zajmuje się przechowywaniem i dostarczaniem poczty przychodzącej z serwera docelowego do klienta poczty, czyli MUA.  W wysyłce przytoczonego wcześniej przeciętnego e-maila wezmą udział następujące moduły: MUA -> MTA -> MTA -> MDA -> MUA. Jak widać jest to dość złożony proces w porównaniu do HTTP, mimo iż jest to najprostszy model. Dlatego implementacja DIME wcale nie jest prosta.

Architektura DIME składa się z wielu niezależnie zaszyfrowanych warstw oraz menadżera kluczy szyfrujących. Poza tym, jest tak przemyślany, aby każdy podmiot biorący udział w dostarczaniu listu
miał dostęp tylko do minimum potrzebnych mu danych aby wykonać swoje zadanie. Z grubsza możemy wydzielić trzy niezależnie szyfrowane warstwy: koperta (zawiera dane dla serwera źródłowego i docelowego), nagłówek i treść listu. Mimo, iż w warstwie koperty znajdują się dane dla obu serwerów, to są one szyfrowane oddzielnymi kluczami, w wyniku czego serwer nadawcy (Origin) nie ma dostępu do danych przeznaczonych dla serwera odbiorcy (Destination).

Warstwa Envelope (koperta) obsługiwana jest głównie przez agenta MTA, nagłówek obsługiwany jest zarówno przez MUA i MDA, w zależności po której stronie przetwarzanie ma miejsce (nadawca SMTP i odbiorca POP3). Warto nadmienić, że w DIME mamy odczynienie z protokołami Dark Mail Transfer Protocol (DMTP), a nie SMTP i będziemy mieli odczynienia z DMAP zamiast IMAP. W wyniku takiej architektury serwer nadawcy (MTA) nie ma dostępu (klucza) do warstwy nagłówka listu i nie zna adresu odbiorcy. Z kolei serwer odbiorcy nie zna adresu e-mail nadawcy, ponieważ znajduje się on w zaszyfrowanej dla niego warstwie nagłówka, do której klucze posiadają tylko nadawca i odbiorca listu. Dzięki takiemu podejściu nie wystarczy dostęp do któregokolwiek z serwerów poczty aby rozszyfrowaną treść wiadomości, a nawet adresata lub odbiorce w zależności od tego, który serwer został skompromitowany. Do treści listu dostęp mają tylko nadawca i odbiorca listu. DIME korzysta również opcjonalnie z DNSSEC w celu weryfikowania autentyczności domen biorących udział w procesie transportu poczty.

Głównym założeniem projektu Dark Mail jest stworzenie ogólnodostępnego (na zasadach open source) standardu przesyłania szyfrowanej poczty w łatwy do użycia sposób, który w przyszłości zastąpiłby obecny standard poczty elektronicznej. Zaszyfrowany list w architekturze DIME podczas przesyłania przez otwarty Internet dostarcza tylko informacji na temat serwera (hosta) docelowego i źródłowego, nic poza tym. Całość mechanizmu przypomina rosyjską matrioszkę, im głębiej tym mniej podmiotów posiada do niej klucz. Takie podejście gwarantuje nienaruszalność treści listu, co zaczyna budzić duże kontrowersje, zarówno po stronie przeciwników jak i zwolenników. Jednak jak zostało napisane wcześniej, obecnie implementacja DIME ma bardziej charakter demonstracyjny niż produkcyjny, ale już istnieją plany jego implementacji w serwerze Postfix. Nie mniej jednak do upowszechnienia się DIME czeka go jeszcze długa droga, być może nie tylko techniczna ale i prawna, a raczej polityczna.

Dark Internet Mail Environment: Architecture and Specifications [pdf]