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]