Wirtualne sieci LAN (VLAN) stanowią fundamentalną technologię segmentacji ruchu w nowoczesnych sieciach komputerowych. W odróżnieniu od fizycznej topologii, VLAN umożliwia logiczne grupowanie urządzeń niezależnie od ich przyłączenia do przełącznika. Dzięki temu administrator może wydzielić osobne sieci dla działów księgowości, marketingu czy kadr, używając tego samego sprzętu sieciowego.
Technologia ta bezpośrednio wiąże się z koncepcją VPN, gdyż tunele warstwy 2 często przenoszą ramki z oznacznikami VLAN między odległymi lokalizacjami. W środowisku rozproszonym VLAN-y definiowane lokalnie muszą być spójne po obu stronach tunelu, aby zachować poprawną segmentację. W praktyce oznacza to konieczność przemyślanego planowania identyfikatorów VLAN w całej organizacji.
Połączenie VLAN z VPN daje elastyczność budowania rozległych sieci korporacyjnych bez fizycznej obecności switchy w każdej lokalizacji. Należy jednak pamiętać o ograniczeniach związanych z przepustowością i opóźnieniami w tunelach.
Routing L3 i bridging L2 różnią się fundamentalnie sposobem obsługi ruchu sieciowego. W podejściu L3 każdy pakiet jest analizowany pod kątem adresu docelowego IP, a decyzja o przekazaniu opiera się na tablicy routingu. Bridging L2 działa transparentnie na poziomie adresów MAC, nie ingerując w zawartość pakietów IP.
W kontekście VLAN kluczową różnicą jest fakt, że mostkowanie przenosi cały ruch rozgłoszeniowy, podczas gdy routing go zatrzymuje na granicy podsieci. W sieciach VLAN routing międzysieciowy (inter-VLAN routing) odbywa się zazwyczaj przez router lub przełącznik warstwy 3, który łączy poszczególne VLAN-y. Bez tego urządzenia z różnych VLAN nie mogłyby się ze sobą komunikować.
Wybór między L2 a L3 w tunelach VPN zależy przede wszystkim od wymagań aplikacji. Protokoły odkrywania usług, takie jak mDNS czy LLMNR, wymagają wspólnej domeny rozgłoszeniowej, a więc mostkowania L2. Z kolei routowanie L3 zapewnia lepszą kontrolę, bezpieczeństwo i skalowalność.
EoIP (Ethernet over IP) to protokół opracowany przez firmę MikroTik, który kapsułkuje całe ramki Ethernet w pakiety IP. Mechanizm ten pozwala na tworzenie wirtualnego połączenia kablowego między dwoma odległymi przełącznikami lub routerami. Dzięki EoIP urządzenia końcowe komunikują się tak, jakby znajdowały się w tej samej fizycznej sieci LAN.
W kontekście VLAN protokół EoIP ma szczególne znaczenie, ponieważ przenosi ramki z oznacznikami 802.1Q bez ich modyfikacji. Oznacza to, że tagi VLAN są zachowywane podczas transmisji przez tunel, co umożliwia rozszerzanie magistral VLAN przez Internet. Administrator może więc utrzymać spójną segmentację między oddziałami firmy.
Należy pamiętać, że EoIP nie szyfruje danych, dlatego w zastosowaniach produkcyjnych wymaga uzupełnienia o protokół IPSec. W RouterOS wystarczy dodać klucz w polu ipsec-secret, aby automatycznie zabezpieczyć tunel przed nieuprawnionym dostępem.
# Konfiguracja Routera A (Centrala)
/interface eoip add name=eoip-oddzial-B remote-address=203.0.113.10 tunnel-id=100
# Konfiguracja Routera B (Oddział)
/interface eoip add name=eoip-centrala-A remote-address=198.51.100.1 tunnel-id=100
Konfiguracja interfejsu EoIP w RouterOS wymaga podania kilku kluczowych parametrów. Najważniejszym z nich jest identyfikator tunelu (tunnel-id), który musi być identyczny po obu stronach połączenia. Dodatkowo należy określić zdalny adres IP, czyli publiczny adres routera przeciwległego.
Parametr tunnel-id pełni rolę identyfikatora sesji i pozwala na utworzenie wielu niezależnych tuneli EoIP między tymi samymi urządzeniami. Każdy tunel może następnie obsługiwać inne VLAN-y lub być dodany do innego mostka. Jest to szczególnie przydatne w scenariuszach, gdy różne działy firmy wymagają osobnych połączeń.
Po utworzeniu interfejsu EoIP pojawia się on w systemie jako wirtualna karta sieciowa, którą można konfigurować jak zwykły port Ethernet. Należy jednak pamiętać o odpowiednim ustawieniu MTU na tym interfejsie, aby uniknąć problemów z fragmentacją pakietów podczas transmisji.
# Router A
/interface bridge port add bridge=bridge-local interface=eoip-oddzial-B
# Router B
/interface bridge port add bridge=bridge-local interface=eoip-centrala-A
Dodanie interfejsu EoIP do mostka sieciowego to kluczowy krok w budowie rozległej sieci L2. Po wykonaniu tej operacji pakiety Ethernet z lokalnego LAN są przekazywane przez tunel do zdalnej lokalizacji i odwrotnie. Proces ten jest całkowicie transparentny dla urządzeń końcowych, które nie wiedzą o istnieniu tunelu VPN.
W kontekście VLAN mostkowanie EoIP pozwala na swobodny przepływ ramek tagowanych między przełącznikami w różnych lokalizacjach. Oznacza to, że konfiguracja VLAN wykonana na głównym przełączniku w centrali jest automatycznie honorowana również w oddziale. Jest to szczególnie wygodne w przypadku zarządzania siecią o jednolitej polityce segmentacji.
Należy jednak zachować ostrożność przy dodawaniu wielu tuneli do tego samego mostka. W przypadku zapętlenia topologii może dojść do burzy rozgłoszeniowej, która sparaliżuje całą sieć. Dlatego zaleca się włączanie protokołu RSTP na mostku, który automatycznie wykryje i zablokuje nadmiarowe ścieżki.
Unikalność adresów MAC w sieciach L2 VPN jest kluczowa dla prawidłowego działania mostka. RouterOS automatycznie generuje losowy adres MAC dla każdego nowego interfejsu EoIP, jednak podczas kopiowania konfiguracji między urządzeniami łatwo o przypadkowe powielenie tego samego adresu. Problem ten dotyczy szczególnie sytuacji, gdy administrator tworzy symetryczne konfiguracje po obu stronach tunelu.
Powielony adres MAC na jednym mostku prowadzi do zjawiska MAC Flapping, czyli ciągłej zmiany przypisania adresu MAC do portów mostka. Objawia się to ostrzeżeniami w logach systemowych oraz niestabilnością połączenia, ponieważ przełącznik nieustannie aktualizuje swoją tablicę adresów MAC. W skrajnych przypadkach może to całkowicie uniemożliwić komunikację między urządzeniami.
Rozwiązaniem tego problemu jest ręczne ustawienie unikalnego adresu MAC dla każdego interfejsu EoIP. W RouterOS można to zrobić w zakładce interfejsu, wpisując żądany adres w polu Admin MAC. Zaleca się przyjęcie konwencji nazewniczej, która jednoznacznie identyfikuje każdy interfejs.
Standard IEEE 802.1Q definiuje mechanizm oznaczania ramek Ethernet za pomocą 4-bajtowego znacznika VLAN. Znacznik ten jest wstawiany między adres źródłowy a pole długości lub typu w ramce Ethernet, co zwiększa jej rozmiar do 1522 bajtów. Wartość CRC ramki jest ponownie przeliczana, aby uwzględnić dodane pole.
W znaczniku 802.1Q najważniejszym polem jest 12-bitowy identyfikator VLAN ID (VID), który pozwala na rozróżnienie do 4096 sieci wirtualnych. Pole Priority Code Point (PCP) umożliwia oznaczanie priorytetu ramki zgodnie z mechanizmem QoS, a Canonical Format Indicator (CFI) informuje o formacie adresu MAC. Dzięki tym informacjom przełączniki mogą podejmować decyzje o przekazywaniu ramek.
W tunelach VPN znaczniki 802.1Q są przenoszone bez zmian, co pozwala na zachowanie spójnej segmentacji VLAN między lokalizacjami. Należy jednak pamiętać, że nie wszystkie protokoły tunelowania obsługują ramki przekraczające standardowy rozmiar 1518 bajtów, co może wymagać dostosowania MTU.
Obsługa magistral VLAN przez tunele VPN to jedno z najważniejszych zastosowań technologii L2 VPN. Gdy tunel EoIP przenosi ramki z oznacznikami 802.1Q, przełączniki po obu stronach widzą go jako zwykły port trunkowy. Umożliwia to budowanie rozproszonych sieci VLAN, w których te same grupy urządzeń są dostępne we wszystkich lokalizacjach.
W praktyce oznacza to, że na przykład VLAN 10 zarezerwowany dla drukarek w centrali jest automatycznie dostępny również w oddziałach. Komputery w oddziale mogą więc bezpośrednio drukować na urządzeniach znajdujących się w innym mieście, bez konieczności konfigurowania przekierowania portów czy tunelowania IP. Jest to szczególnie przydatne w przypadku scentralizowanych usług sieciowych.
Należy jednak pamiętać, że rozszerzanie VLAN przez VPN zwiększa domenę rozgłoszeniową i może prowadzić do nadmiernego ruchu broadcast. Z tego powodu zaleca się ograniczenie liczby VLAN przenoszonych przez tunel tylko do tych, które są absolutnie niezbędne. Filtrowanie ramek na mostku pomaga zminimalizować niepożądany ruch.
Problem MTU (Maximum Transmission Unit) w tunelach L2 z VLAN wynika z kumulacji narzutów poszczególnych warstw enkapsulacji. Standardowa ramka Ethernet ma maksymalnie 1500 bajtów danych, ale znacznik VLAN dodaje kolejne 4 bajty, co daje 1504 bajty. Narzut protokołu EoIP obejmujący nagłówek GRE i IP to dodatkowe 42 bajty.
Gdy suma narzutów przekracza MTU interfejsu WAN, pakiety muszą być fragmentowane przed wysłaniem w sieć publiczną. Fragmentacja znacząco obniża wydajność, ponieważ każdy fragment wymaga osobnego przetworzenia i ponownego złożenia po stronie odbiorcy. W skrajnych przypadkach może prowadzić do całkowitego zerwania połączenia, zwłaszcza w przypadku aplikacji wrażliwych na opóźnienia.
Rozwiązaniem jest obniżenie MTU na interfejsach wewnątrz tunelu do wartości, która uwzględnia wszystkie narzuty. Dla typowego tunelu EoIP z VLAN zaleca się ustawienie MTU na poziomie około 1450 bajtów. Dodatkowo mechanizm MSS Clamping dla połączeń TCP zapobiega fragmentacji poprzez negocjowanie mniejszego rozmiaru segmentu już na etapie nawiązywania połączenia.
Bridge Control Protocol (BCP) to rozszerzenie protokołu PPP umożliwiające mostkowanie ramek Ethernet w sesjach połączeniowych. W przeciwieństwie do EoIP, które wymaga stałego publicznego adresu IP po obu stronach, BCP działa w ramach istniejącej sesji PPP nawiązanej przez PPTP, L2TP lub SSTP. Dzięki temu klienci z dynamicznymi adresami IP mogą uczestniczyć w rozproszonej sieci L2.
Mechanizm BCP jest szczególnie przydatny w scenariuszach, gdy odległy router łączy się z centralą przez modem LTE lub inny dostęp o zmiennym adresacji. Po nawiązaniu sesji VPN i wynegocjowaniu BCP, interfejs klienta jest automatycznie dodawany do mostka sieciowego w centrali. Urządzenia w oddziale stają się wówczas widoczne w firmowej sieci LAN.
Ograniczeniem BCP jest jego zależność od protokołu PPP oraz brak natywnego wsparcia w systemach Windows. W praktyce stosuje się go głównie w ekosystemie MikroTik, gdzie konfiguracja sprowadza się do ustawienia parametru bridge w profilu PPP. Warto również pamiętać, że BCP przenosi ramki VLAN, co pozwala na segmentację ruchu w ramach mostkowanej sesji.
bridge=bridge-local wewnątrz wybranego profilu.
Konfiguracja BCP w profilach PPP RouterOS wymaga jedynie wskazania mostka, do którego ma zostać dodany interfejs klienta. Po ustawieniu parametru bridge w odpowiednim profilu, każda nowa sesja PPP automatycznie włącza interfejs klienta do wskazanego mostka. Jest to wygodne rozwiązanie w przypadku wielu klientów łączących się zdalnie.
W kontekście VLAN konfiguracja BCP pozwala na precyzyjne określenie, które VLAN-y będą dostępne dla danego klienta. Poprzez zastosowanie filtrowania na mostku można ograniczyć dostęp zdalnych urządzeń tylko do wybranych sieci wirtualnych. Zwiększa to bezpieczeństwo i zapobiega nieautoryzowanemu dostępowi do wrażliwych zasobów.
Warto pamiętać, że BCP działa w trybie klient-serwer, co oznacza, że tylko serwer PPP może inicjować proces mostkowania. Klient nie ma możliwości wymuszenia dodania swojego interfejsu do mostka bez odpowiedniej konfiguracji po stronie serwera. Daje to administratorowi pełną kontrolę nad tym, które urządzenia mogą korzystać z mostkowania L2.
Technologia Q-in-Q, zdefiniowana w standardzie IEEE 802.1ad, umożliwia podwójne tagowanie ramek Ethernet. Zewnętrzny znacznik S-Tag (Service Tag) należy do dostawcy usług i identyfikuje klienta w sieci szkieletowej. Wewnętrzny znacznik C-Tag (Customer Tag) jest kontrolowany przez klienta i służy do segmentacji jego własnej sieci.
W tunelach VPN Q-in-Q odgrywa istotną rolę, ponieważ umożliwia operatorowi dostarczenie transparentnej usługi VLAN dla klienta. Klient może używać własnych identyfikatorów VLAN bez obawy o kolizję z innymi klientami operatora. Dzięki EoIP i VXLAN ramki z podwójnym tagiem są przenoszone bez modyfikacji między lokalizacjami.
Zastosowanie Q-in-Q jest szczególnie popularne w sieciach operatorskich, gdzie jeden dostawca obsługuje wielu klientów korporacyjnych. Każdy klient otrzymuje własny S-Tag, a wewnątrz może swobodnie zarządzać swoją przestrzenią VLAN. Rozwiązanie to upraszcza zarządzanie siecią szkieletową i zwiększa elastyczność świadczonych usług.
OpenVPN w trybie TAP emuluje wirtualną kartę sieciową Ethernet, co odróżnia go od standardowego trybu TUN działającego na poziomie IP. Tryb TAP pozwala na przesyłanie pełnych ramek Ethernet, włączając w to znaczniki VLAN, ramki ARP oraz transmisje rozgłoszeniowe. Jest to kluczowe w scenariuszach wymagających transparentności warstwy 2.
Po zmostkowaniu interfejsu TAP z fizycznym LAN-em serwera, zdalny klient staje się pełnoprawnym członkiem sieci lokalnej. Otrzymuje adres IP z lokalnego serwera DHCP i może korzystać ze wszystkich usług dostępnych w danej podsieci. Jest to szczególnie przydatne dla pracowników zdalnych, którzy potrzebują dostępu do zasobów sieciowych w sposób nieodróżnialny od pracy w biurze.
Tryb TAP ma jednak swoje wady, w tym większy narzut protokołu i większe zużycie przepustowości z powodu transmitowania ruchu rozgłoszeniowego. Ponadto mostkowanie L2 w OpenVPN wymaga starannej konfiguracji i jest mniej skalowalne niż tryb TUN. W środowiskach korporacyjnych zaleca się stosowanie trybu TAM tylko w uzasadnionych przypadkach.
dev tap.
OpenVPN TAP na systemie Windows wymaga zastosowania sterownika wirtualnej karty sieciowej, który jest dostarczany wraz z instalatorem OpenVPN. Po zmianie dyrektywy dev tap w pliku konfiguracyjnym, system Windows tworzy nowy wirtualny adapter sieciowy. Adapter ten jest widoczny w Menedżerze urządzeń i Panelu sterowania jako dodatkowa karta sieciowa.
Jedną z największych zalet trybu TAP w Windows jest możliwość korzystania z lokalnego serwera DHCP w biurze. Zdalny klient otrzymuje adres IP, maskę, bramę domyślną i serwery DNS automatycznie, bez ręcznej konfiguracji. Działa to szczególnie dobrze w środowiskach korporacyjnych wykorzystujących scentralizowane zarządzanie adresacją IP.
Niestety tryb TAP w Windows wiąże się również z pewnymi ograniczeniami. Ruch rozgłoszeniowy generowany przez system Windows, taki jak NetBIOS czy LLMNR, jest transmitowany przez tunel, co zwiększa obciążenie łącza. Ponadto niektóre aplikacje antywirusowe i zapory sieciowe mogą blokować działanie wirtualnego adaptera TAP, co wymaga dodatkowej konfiguracji.
VXLAN (Virtual Extensible LAN) to nowoczesna technologia wirtualizacji sieci warstwy 2, która działa w oparciu o enkapsulację MAC-over-UDP. W przeciwieństwie do tradycyjnych rozwiązań L2 VPN, VXLAN został zaprojektowany z myślą o skalowalności w centrach danych i środowiskach chmurowych. Standard ten jest obsługiwany przez większość liczących się producentów sprzętu sieciowego.
Najważniejszą zaletą VXLAN w porównaniu do tradycyjnych VLAN jest ogromna przestrzeń adresowa. Zamiast ograniczonych 4096 identyfikatorów VLAN, VXLAN oferuje 24-bitowy identyfikator VNI umożliwiający rozróżnienie ponad 16 milionów sieci wirtualnych. Jest to kluczowe w środowiskach wielodzierżawczych, gdzie każdy klient wymaga izolacji na poziomie warstwy 2.
VXLAN wykorzystuje standardowy protokół UDP z portem 4789, co ułatwia integrację z istniejącą infrastrukturą sieciową. Dzięki enkapsulacji w UDP, pakiety VXLAN mogą być routowane przez sieci IP, co eliminuje ograniczenie tradycyjnych VLAN do pojedynczej domeny rozgłoszeniowej. W kontekście VPN, VXLAN over IPSec stanowi wydajne i bezpieczne rozwiązanie do łączenia odległych centrów danych.
/interface vxlan add name=vxlan-tunel vni=1000 port=4789
/interface vxlan vteps add interface=vxlan-tunel remote-ip=203.0.113.5
Konfiguracja VXLAN w RouterOS w wersji 7 jest stosunkowo prosta i opiera się na dwóch głównych krokach. Najpierw tworzymy interfejs VXLAN z określeniem identyfikatora VNI oraz numeru portu. Następnie definiujemy punkty końcowe VTEP (VXLAN Tunnel End Point), podając adresy IP zdalnych routerów, które mają uczestniczyć w tunelu.
Po utworzeniu interfejs VXLAN można dodać do mostka sieciowego w taki sam sposób jak interfejs EoIP. Różnica polega na tym, że VXLAN jest bardziej skalowalny w topologiach typu wiele-do-wielu, gdzie każdy węzeł musi komunikować się z wieloma innymi. VXLAN wykorzystuje mechanizm uczenia się adresów MAC podobny do tradycyjnych przełączników.
W przeciwieństwie do EoIP, VXLAN nie wymaga unikalnych identyfikatorów tunelu dla każdego połączenia. Wystarczy jeden interfejs VXLAN z odpowiednim VNI, a następnie dodać wielu zdalnych VTEP. Dzięki temu konfiguracja w rozproszonych środowiskach jest prostsza i bardziej przejrzysta. VXLAN sprawdza się szczególnie dobrze w połączeniu z WireGuard jako warstwą szyfrującą.
Pętle w warstwie 2 stanowią jedno z najpoważniejszych zagrożeń w sieciach L2 VPN. W przeciwieństwie do warstwy 3, gdzie pakiet ma pole TTL ograniczające jego żywotność, ramki Ethernet nie posiadają takiego mechanizmu. Oznacza to, że ramka zapętlona będzie krążyć w sieci w nieskończoność, mnożąc się i powodując lawinowy wzrost ruchu.
W kontekście tuneli VPN pętle mogą powstać na przykład przez przypadkowe utworzenie dwóch tuneli EoIP między tymi samymi lokalizacjami. Gdy oba tunele zostaną dodane do tego samego mostka, powstaje logiczna pętla, która błyskawicznie prowadzi do burzy rozgłoszeniowej. Objawia się to 100-procentowym wykorzystaniem procesora routera i całkowitym brakiem komunikacji sieciowej.
Jedynym skutecznym zabezpieczeniem przed pętlami L2 jest zastosowanie protokołu Spanning Tree Protocol (STP) lub jego nowszej wersji Rapid STP (RSTP). Protokół ten wykrywa nadmiarowe ścieżki i blokuje jeden z portów, aby przerwać pętlę. W RouterOS mostek ma domyślnie włączone RSTP, co zapewnia podstawową ochronę przed tym zagrożeniem.
Rapid Spanning Tree Protocol (RSTP) jest ulepszoną wersją klasycznego STP, oferującą szybszą zbieżność po zmianie topologii sieci. W środowiskach tunelowych VPN RSTP odgrywa kluczową rolę w zapewnieniu niezawodności połączeń L2. Gdy protokół wykryje redundantną ścieżkę przez tunel VPN, wprowadza jeden z portów w stan blokowania, zapobiegając powstawaniu pętli.
W przypadku awarii głównego tunelu, RSTP automatycznie odblokowuje port zapasowy, przywracając łączność w czasie zaledwie kilku sekund. Jest to znacząca poprawa w stosunku do klasycznego STP, który potrzebował nawet 50 sekund na przeliczenie topologii. W środowiskach VPN oznacza to szybsze przywrócenie komunikacji po awarii łącza.
Aby RSTP działał poprawnie w sieci rozproszonej, należy prawidłowo skonfigurować priorytety mostka i wyznaczyć Most Główny (Root Bridge) w centrali. Wszystkie mostki w oddziałach powinny mieć wyższe wartości priorytetu, aby centrala pełniła rolę nadrzędną. Należy również pamiętać, że RSTP wymaga spójnej konfiguracji na wszystkich przełącznikach w sieci.
Ryzyko związane z DHCP w mostkowanych sieciach VPN wynika z faktu, że zapytania DHCP są transmisjami rozgłoszeniowymi. Wspólna domena rozgłoszeniowa oznacza, że serwer DHCP w centrali może odpowiedzieć na zapytanie klienta w oddziale, przydzielając mu adres z niewłaściwej puli. Prowadzi to do błędnej adresacji IP i problemów z łącznością.
W skrajnych przypadkach klient w oddziale może otrzymać adres IP z sieci centrali, co spowoduje, że cały jego ruch internetowy będzie kierowany przez odległe biuro. Jest to nie tylko nieefektywne ze względu na dodatkowe opóźnienia, ale może również naruszyć politykę bezpieczeństwa firmy. Ponadto konflikty adresów IP mogą całkowicie uniemożliwić komunikację niektórym urządzeniom.
Rozwiązaniem problemu jest zastosowanie mechanizmu DHCP Snooping na mostku, który analizuje ruch DHCP i blokuje nieautoryzowane serwery. Alternatywnie można użyć filtrów mostka (Bridge Filter) do blokowania pakietów UDP na portach 67-68 przychodzących z tunelu. W zaawansowanych konfiguracjach stosuje się DHCP Relay, który kieruje zapytania do odpowiedniego serwera w zależności od VLAN.
# Blokowanie zapytań DHCP przez tunel VPN
/interface bridge filter add chain=forward in-interface=eoip-oddzial-1 mac-protocol=ip ip-protocol=udp dst-port=67-68 action=drop
Filtrowanie ramek na mostku (Bridge Filter) w RouterOS umożliwia selektywne blokowanie lub przepuszczanie ruchu na poziomie warstwy 2. Jest to potężne narzędzie do kontroli ruchu w sieciach L2 VPN, które pozwala na tworzenie reguł opartych na adresach MAC, typach protokołów czy portach. W przeciwieństwie do zapory sieciowej warstwy 3, Bridge Filter działa na ramkach Ethernet przed ich dalszym przetwarzaniem.
W kontekście VLAN i VPN szczególnie przydatne jest blokowanie określonych typów ruchu rozgłoszeniowego przed wejściem w tunel. Na przykład reguła blokująca DHCP na porcie tunelu zapobiega przydzielaniu adresów IP przez niewłaściwy serwer. Można również blokować ruch NetBIOS, LLMNR czy inne protokoły generujące niepotrzebny ruch na łączu WAN.
Bridge Filter oferuje również możliwość limitowania prędkości (rate limiting) dla poszczególnych strumieni ruchu. Pozwala to na przykład ograniczyć przepustowość dla ruchu broadcast, aby nie zdominował on łącza VPN. Filtry mogą być stosowane zarówno w kierunku ingress, jak i egress, co daje pełną kontrolę nad ruchem przechodzącym przez mostek.
Nowoczesne wersje RouterOS oferują zintegrowane wsparcie dla szyfrowania IPSec bezpośrednio w konfiguracji interfejsów tunelowych. Wystarczy uzupełnić pole ipsec-secret w interfejsie EoIP lub GRE, aby router automatycznie utworzył niezbędne polityki IPSec w trybie transportowym. Znacząco upraszcza to proces zabezpieczania tuneli L2 przed nieuprawnionym dostępem.
Automatyczna konfiguracja IPSec eliminuje konieczność ręcznego definiowania propozycji szyfrowania, kluczy i polityk. Router sam dobiera odpowiednie parametry, takie jak algorytm szyfrowania AES czy uwierzytelnienie SHA. Administrator musi jedynie zadbać o bezpieczne przechowywanie klucza PSK (Pre-Shared Key) użytego do uwierzytelnienia obu stron.
Warto pamiętać, że IPSec w trybie transportowym szyfruje tylko dane, pozostawiając nagłówek IP oryginalnego pakietu niezaszyfrowany. Jest to wystarczające dla tuneli EoIP, ponieważ cała ramka Ethernet jest przenoszona jako dane w pakiecie IP. Dla dodatkowego bezpieczeństwa można zastosować tryb tunelowy IPSec, który enkapsuluje cały oryginalny pakiet.
Mechanizm Fast Path w RouterOS został zaprojektowany w celu przyspieszenia przetwarzania pakietów przez omijanie niektórych etapów w stosie sieciowym. Gdy Fast Path jest aktywny dla interfejsu tunelowego, pakiety są przesyłane bezpośrednio między interfejsem wejściowym a wyjściowym, z pominięciem dodatkowego przetwarzania. Przekłada się to na wyższą przepustowość i mniejsze opóźnienia.
W przypadku tuneli EoIP z VLAN mechanizm Fast Path może znacząco poprawić wydajność, szczególnie przy dużym natężeniu ruchu. Należy jednak pamiętać, że Fast Path nie jest kompatybilny ze wszystkimi funkcjami RouterOS, takimi jak filtrowanie na mostku czy kolejkowanie. Włączenie tych funkcji może spowodować automatyczne wyłączenie Fast Path dla danego interfejsu.
Głównym hamulcem wydajności tuneli L2 jest fragmentacja pakietów, która wymaga kosztownego obliczeniowo składania ramek po stronie odbiorcy. Aby zminimalizować ten problem, zaleca się stosowanie ramek Jumbo Frames w sieci szkieletowej oraz odpowiednie ustawienie MTU. Prawidłowo skonfigurowany Fast Path w połączeniu z optymalnym MTU może znacząco zwiększyć wydajność tunelu VPN.
Agregacja łącz przez VPN pozwala na sumowanie przepustowości kilku fizycznych łączy w jeden logiczny interfejs. W środowisku tunelowym L2 można utworzyć kilka niezależnych tuneli EoIP, a następnie połączyć je w interfejs Bonding. Tryby Balance-RR (Round Robin) lub LACP (Link Aggregation Control Protocol) umożliwiają równomierne rozłożenie ruchu między tunelami.
Rozwiązanie to jest szczególnie przydatne w sytuacjach, gdy pojedyncze łącze nie zapewnia wystarczającej przepustowości, a dostępne są dwa lub więcej łączy od różnych dostawców. Na przykład można połączyć łącze światłowodowe z modemem LTE, tworząc agregację o sumarycznej przepustowości. W przypadku awarii jednego z łączy, ruch jest automatycznie przekierowywany na pozostałe.
Należy jednak pamiętać o wyzwaniach związanych z agregacją tuneli VPN. Różnice w opóźnieniach między poszczególnymi łączami mogą powodować dostarczanie pakietów TCP poza kolejnością, co negatywnie wpływa na wydajność. Ponadto protokół LACP wymaga wzajemnej negocjacji między urządzeniami, co może być trudne do osiągnięcia przez tunel VPN o zmiennych parametrach.
VPLS (Virtual Private LAN Service) to standard operatorski umożliwiający budowanie rozległych sieci Ethernet przez szkielet MPLS. W przeciwieństwie do prostych tuneli punkt-punkt, VPLS tworzy wirtualną sieć LAN w topologii mesh, gdzie każdy węzeł może komunikować się z każdym innym. Jest to rozwiązanie stosowane głównie przez dużych dostawców usług internetowych.
VPLS wykorzystuje protokoły MPLS i LDP do dystrybucji informacji o etykietach oraz uczenia się adresów MAC. W warstwie 2 VPLS zachowuje się jak jeden wielki przełącznik rozproszony geograficznie, który automatycznie uczy się lokalizacji poszczególnych adresów MAC. Dzięki temu ruch między oddziałami jest kierowany optymalną ścieżką bez zbędnego zalewania sieci.
W kontekście VLAN, VPLS umożliwia przenoszenie ramek z oznacznikami 802.1Q między wszystkimi lokalizacjami uczestniczącymi w usłudze. Każdy klient może posiadać własną przestrzeń VLAN, która jest izolowana od innych klientów operatora. VPLS jest jednak rozwiązaniem kosztownym i skomplikowanym w konfiguracji, dostępnym głównie w sieciach operatorskich.
Monitoring CCTV w warstwie 2 to praktyczny przykład zastosowania tuneli L2 VPN. Większość systemów monitoringu IP wykorzystuje protokół ONVIF do wykrywania kamer, który bazuje na transmisjach rozgłoszeniowych. Bez wspólnej domeny L2 rejestrator NVR w centrali nie jest w stanie automatycznie wykryć kamer znajdujących się w odległym magazynie lub oddziale.
Dzięki tunelowi EoIP lub VXLAN ramki rozgłoszeniowe ONVIF swobodnie przepływają między lokalizacjami, umożliwiając automatyczne wykrywanie i konfigurację kamer. Rejestrator widzi wszystkie kamery tak, jakby były podłączone do tego samego przełącznika, co znacznie upraszcza proces wdrożenia. Eliminuje to konieczność ręcznego dodawania każdej kamery po adresie IP.
Należy jednak pamiętać, że monitoring CCTV generuje znaczny ruch sieciowy, szczególnie w przypadku kamer wysokiej rozdzielczości. Przenoszenie tego ruchu przez tunel VPN wymaga odpowiedniej przepustowości łącza WAN. Zaleca się stosowanie oddzielnego VLAN dla kamer i ograniczenie przepustowości, aby ruch monitoringu nie zakłócał działania innych usług w sieci.
/ping 192.168.1.1 arp-ping=yes./interface bridge host print.
Narzędzie ARP-Ping w RouterOS umożliwia testowanie łączności na poziomie warstwy 2, co jest kluczowe w diagnostyce tuneli L2 VPN. W przeciwieństwie do standardowego ping ICMP działającego na warstwie 3, ARP-Ping wysyła zapytanie ARP i oczekuje na odpowiedź od urządzenia docelowego. Jeśli odpowiedź ARP dociera przez tunel, oznacza to, że ramki Ethernet są poprawnie przesyłane.
Typowy scenariusz diagnostyczny polega na wykonaniu ARP-Ping z routera w centrali do urządzenia w oddziale. Jeśli ARP-Ping działa, a zwykły ping nie, problem leży w konfiguracji routingu lub firewalla, a nie w tunelu L2. Z kolei brak odpowiedzi ARP-Ping przy skonfigurowanym tunelu sugeruje problem z mostkiem lub filtrami na którymś z routerów.
Dodatkowym narzędziem diagnostycznym jest przeglądanie tablicy hostów mostka za pomocą polecenia /interface bridge host print. Pokazuje ono wszystkie adresy MAC, które mostek nauczył się na poszczególnych portach. Jeśli w tablicy brakuje adresów MAC z drugiej strony tunelu, oznacza to problem z komunikacją L2 między lokalizacjami.
Pętla NAT (Hairpin NAT) to nieefektywność występująca w rozległych sieciach L2 VPN, gdzie bramą domyślną dla wszystkich urządzeń jest router centralny. Gdy host w oddziale chce uzyskać dostęp do Internetu, jego zapytanie musi najpierw przejść przez tunel VPN do centrali, a dopiero stamtąd trafić do sieci publicznej. Powoduje to dwukrotne pokonanie łącza WAN i niepotrzebne obciążenie.
Problem ten nasila się wraz ze wzrostem liczby oddziałów i ilości generowanego ruchu internetowego. Każde połączenie HTTP, każde pobranie pliku czy aktualizacja systemu musi być przetransmitowana przez tunel do centrali, co marnuje cenną przepustowość. Jest to główny argument przeciwników stosowania mostkowania L2 w sieciach wielooddziałowych.
Rozwiązaniem jest zastosowanie lokalnego NAT w każdym oddziale, tak aby ruch internetowy był kierowany bezpośrednio do sieci publicznej. Wymaga to jednak rezygnacji z płaskiej sieci L2 na rzecz routingu L3, gdzie każdy oddział ma własną podsieć i własną bramę domyślną. Alternatywnie można skonfigurować politykę routingu, która kieruje tylko ruch do sieci firmowej przez tunel, a resztę bezpośrednio do Internetu.
IPIP (IP over IP) i EoIP to dwa różne protokoły tunelowania oferowane przez RouterOS, które różnią się przede wszystkim warstwą działania. IPIP enkapsuluje tylko pakiety IP, dodając jedynie 20-bajtowy nagłówek IP przed oryginalnym pakietem. EoIP z kolei enkapsuluje całe ramki Ethernet, używając nagłówka GRE o większym narzucie.
Wybór między IPIP a EoIP zależy od wymagań konkretnego zastosowania. IPIP jest wydajniejszy i ma mniejszy narzut, ale nie obsługuje protokołów innych niż IP oraz nie pozwala na mostkowanie L2. EoIP jest bardziej uniwersalny, obsługuje VLAN, ARP i transmisje rozgłoszeniowe, ale kosztem większego obciążenia i mniejszej wydajności.
W kontekście VLAN, EoIP jest zdecydowanie lepszym wyborem, ponieważ przenosi ramki z oznacznikami 802.1Q w nienaruszonym stanie. IPIP nie umożliwia transmisji znaczników VLAN, ponieważ działa wyłącznie na pakietach IP. Dla sieci wymagających segmentacji VLAN przez VPN, EoIP jest więc jedynym właściwym wyborem spośród tych dwóch protokołów.
Wydajność tuneli L2 VPN jest w znacznym stopniu ograniczona przez moc obliczeniową procesora routera. Każda ramka Ethernet musi zostać skapsułkowana w pakiet IP z odpowiednimi nagłówkami, co wymaga cykli procesora. W przypadku wielu jednoczesnych tuneli lub dużego natężenia ruchu, obciążenie CPU może stać się wąskim gardłem ograniczającym przepustowość.
Opóźnienie (latency) ma szczególnie negatywny wpływ na protokoły warstwy aplikacji działające przez tunele L2. Protokół SMB używany do udostępniania plików w sieciach Windows jest bardzo wrażliwy na opóźnienia i źle znosi wysokie wartości RTT. Nawet przy dużej przepustowości łącza, wysokie opóźnienie może sprawić, że kopiowanie plików przez tunel L2 będzie bardzo wolne.
Aby zminimalizować wpływ opóźnień na wydajność, zaleca się stosowanie protokołów zoptymalizowanych pod kątem łączy o dużym RTT. W przypadku SMB warto rozważyć włączenie mechanizmu SMB Multichannel lub zastosowanie protokołów transferu plików opartych na UDP. Dodatkowo pomocne jest zmniejszenie rozmiaru okna TCP oraz zastosowanie mechanizmów przyspieszających, takich jak Fast Path.
# Konfiguracja urządzenia A
/interface vxlan add name=vxlan1 vni=50
/interface vxlan vteps add interface=vxlan1 remote-ip=1.1.1.2
# Dodanie interfejsu do mostka
/interface bridge port add bridge=br-lan interface=vxlan1
VXLAN w trybie Unicast to najprostsza forma konfiguracji tego protokołu, w której pakiety są wysyłane bezpośrednio do konkretnych adresów IP punktów VTEP. W RouterOS wystarczy utworzyć interfejs VXLAN, zdefiniować VNI i dodać zdalne adresy IP sąsiednich urządzeń. Każdy dodany VTEP reprezentuje drugi koniec tunelu VXLAN.
Po dodaniu interfejsu VXLAN do mostka sieciowego, ramki Ethernet są automatycznie enkapsulowane w pakiety UDP i wysyłane do odpowiednich VTEP. VXLAN w trybie Unicast sprawdza się dobrze w topologiach punkt-punkt oraz w małych sieciach z kilkoma węzłami. Dla większych topologii zaleca się stosowanie trybu Multicast lub EVPN.
Zaletą VXLAN w porównaniu do EoIP jest interoperacyjność między urządzeniami różnych producentów. Dzięki standardowemu formatowi enkapsulacji, router MikroTik może komunikować się przez VXLAN z serwerem Linux lub przełącznikiem VMware. Jest to kluczowe w heterogenicznych środowiskach, gdzie różne działy używają sprzętu różnych producentów.
Tryb Safe Mode w RouterOS to niezwykle przydatne narzędzie chroniące przed błędami konfiguracyjnymi, które mogą odciąć administratora od urządzenia. Po włączeniu Safe Mode, wszystkie zmiany konfiguracji są tymczasowe i zostaną automatycznie wycofane w przypadku utraty połączenia z routerem. Jest to szczególnie ważne podczas konfiguracji mostków i VLAN, gdzie błędne ustawienia mogą zablokować dostęp do zarządzania.
Przed rozpoczęciem ryzykownych zmian, takich jak modyfikacja konfiguracji mostka, dodawanie nowych VLAN czy zmiana adresacji IP, należy aktywować Safe Mode. W interfejsie WinBox można to zrobić klikając ikonę tarczy, a w konsoli za pomocą skrótu Ctrl+X. Router będzie wówczas monitorował stan połączenia i w razie jego utraty przywróci poprzednią konfigurację.
Po pomyślnym zakończeniu konfiguracji należy ręcznie wyłączyć Safe Mode, zatwierdzając wprowadzone zmiany. Jeśli połączenie zostanie zerwane przed wyłączeniem Safe Mode, router automatycznie cofnie wszystkie zmiany dokonane w tym trybie. Jest to mechanizm bezpieczeństwa, który uratował wielu administratorów przed koniecznością fizycznego dostępu do urządzenia.
RoMON (Router Management Overlay Network) to autorska technologia MikroTik umożliwiająca zarządzanie urządzeniami w warstwie 2. RoMON tworzy nakładkową sieć zarządzania, która działa niezależnie od konfiguracji IP poszczególnych routerów. Dzięki temu administrator może zarządzać urządzeniami nawet wtedy, gdy mają one błędnie skonfigurowany adres IP.
W połączeniu z tunelami L2 VPN, RoMON umożliwia zarządzanie przełącznikami i routerami w odległych lokalizacjach bez konieczności adresowania ich publicznymi IP. Wystarczy, że tunele EoIP lub sesje BCP przenoszą ruch RoMON między lokalizacjami. Administrator w centrali może wówczas przeglądać i konfigurować urządzenia w oddziałach tak, jakby były lokalne.
RoMON automatycznie odkrywa sąsiednie urządzenia MikroTik w tej samej domenie rozgłoszeniowej, co działa również przez tunele L2. Jest to szczególnie przydatne w scenariuszach, gdzie w oddziale znajduje się wiele urządzeń MikroTik, którymi trzeba zarządzać. RoMON over VPN znacząco upraszcza administrację rozproszoną siecią.
WireGuard to nowoczesny protokół VPN znany z wysokiej wydajności i prostoty konfiguracji, jednak jego głównym ograniczeniem jest działanie wyłącznie w warstwie 3. WireGuard nie emuluje wirtualnej karty Ethernet, a jedynie tworzy interfejs IP, który nie może być bezpośrednio dodany do mostka sieciowego. Jest to celowe założenie projektowe mające na celu uproszczenie i zwiększenie bezpieczeństwa protokołu.
Brak wsparcia dla warstwy 2 w WireGuard nie oznacza jednak, że nie można go używać w scenariuszach L2 VPN. Rozwiązaniem jest tunelowanie tunelu, czyli uruchomienie VXLAN lub EoIP przez interfejs WireGuard. Dzięki takiemu podejściu zyskujemy szybkość i prostotę WireGuarda jako warstwy transportowej oraz funkcjonalność L2 z VXLAN jako warstwy enkapsulacji.
Konfiguracja VXLAN over WireGuard wymaga utworzenia interfejsu WireGuard, a następnie interfejsu VXLAN, który jako adres źródłowy i docelowy używa adresów IP z sieci WireGuard. Taka konstrukcja zapewnia szyfrowanie na poziomie WireGuarda i transparentność L2 na poziomie VXLAN. Jest to coraz popularniejsze rozwiązanie w nowoczesnych sieciach VPN ze względu na wydajność WireGuarda.
VLAN Hopping to technika ataku polegająca na nieautoryzowanym przeskakiwaniu między różnymi VLAN. Atakujący może wykorzystać domyślną konfigurację portów trunkowych, aby wysyłać ramki z oznacznikami VLAN, do których nie powinien mieć dostępu. W środowisku tuneli VPN zagrożenie to jest szczególnie istotne, ponieważ tunel często pełni rolę magistrali dla wielu VLAN.
Najczęstszą metodą VLAN Hopping jest atak typu Switch Spoofing, w którym atakujący podszywa się pod przełącznik i negocjuje utworzenie portu trunkowego. Alternatywną metodą jest Double Tagging, gdzie atakujący wysyła ramkę z podwójnym znacznikiem VLAN, aby ominąć filtry przełącznika. W kontekście VPN, atakujący mógłby próbować wysyłać ramki z fałszywymi tagami przez tunel do sieci centrali.
Zabezpieczenie przed VLAN Hopping wymaga zastosowania kilku środków ostrożności. Należy wyłączyć automatyczną negocjację trunk na wszystkich portach dostępowych i ręcznie definiować dozwolone VLAN-y na portach trunkowych. W RouterOS kluczowe jest włączenie VLAN Filtering na mostku oraz ścisłe określenie, które identyfikatory VLAN mogą być przenoszone przez tunel VPN.
Live Migration maszyn wirtualnych, znana jako vMotion w VMware, wymaga wspólnej domeny warstwy 2 między serwerami. Podczas migracji stan pamięci RAM i procesora maszyny wirtualnej jest przesyłany do innego hosta, a adres IP maszyny pozostaje niezmieniony. Jest to możliwe tylko wtedy, gdy oba hosty znajdują się w tej samej podsieci IP i domenie rozgłoszeniowej.
Tunele L2 VPN, szczególnie VXLAN over IPSec, umożliwiają rozszerzenie warstwy 2 między odległymi centrami danych. Dzięki temu administrator może przenosić działające maszyny wirtualne między serwerowniami bez przerwy w działaniu usług. Jest to kluczowe w scenariuszach disaster recovery, gdzie zapasowe centrum danych znajduje się w innej lokalizacji geograficznej.
Należy jednak pamiętać, że vMotion przez tunel VPN wymaga bardzo stabilnego łącza o niskim opóźnieniu, najlepiej poniżej 10 milisekund RTT. Wyższe opóźnienia mogą powodować przekroczenie limitów czasowych migracji i jej niepowodzenie. Ponadto przepustowość łącza musi być wystarczająca do przesłania obrazu pamięci RAM maszyny wirtualnej w akceptowalnym czasie.
Wybór między L2 a L3 w sieciach VPN to jedna z kluczowych decyzji projektowych, która wpływa na skalowalność, bezpieczeństwo i łatwość zarządzania siecią. W większości przypadków routing L3 jest lepszym wyborem, ponieważ zapewnia naturalną izolację domen rozgłoszeniowych i umożliwia stosowanie zaawansowanych polityk routingu. L3 jest również bardziej skalowalny w miarę dodawania kolejnych oddziałów.
Mostkowanie L2 powinno być stosowane tylko wtedy, gdy jest absolutnie niezbędne. Typowe uzasadnienia to specyficzne aplikacje przemysłowe działające w warstwie 2, protokoły odkrywania usług wymagające rozgłoszeń oraz scenariusze migracji maszyn wirtualnych. W sieciach o ograniczonej przepustowości łączy WAN mostkowanie L2 jest szczególnie niezalecane ze względu na ruch rozgłoszeniowy.
Złota zasada projektowania sieci głosi: rutuj tam, gdzie możesz, mostkuj tylko tam, gdzie musisz. Przestrzeganie tej zasady pozwala uniknąć wielu problemów związanych z wydajnością, bezpieczeństwem i stabilnością sieci. W praktyce oznacza to, że dla typowej sieci korporacyjnej z wieloma oddziałami należy wybrać routing L3 z VPN site-to-site.
EVPN (Ethernet VPN) to nowoczesna technologia stanowiąca ewolucję tradycyjnych sieci L2 VPN. W odróżnieniu od klasycznego uczenia się adresów MAC przez zalewanie sieci (Flood-and-Learn), EVPN wykorzystuje protokół BGP do dystrybucji informacji o lokalizacji adresów MAC. Każdy router uczestniczący w EVPN informuje sąsiadów o adresach MAC dostępnych za jego pośrednictwem.
Zastosowanie BGP eliminiuje nieefektywne mechanizmy znane z tradycyjnych sieci L2, takie jak zalewanie nieznanych adresów MAC czy potrzeba uczenia się na podstawie ruchu. EVPN obsługuje również zaawansowane funkcje, takie jak równoważenie obciążenia ECMP (Equal Cost Multi Path) dla ruchu L2 oraz szybka zbieżność w przypadku awarii. Jest to szczególnie ważne w dużych centrach danych i sieciach operatorskich.
RouterOS w wersji 7 wprowadza wsparcie dla EVPN, co czyni go konkurencyjnym rozwiązaniem dla wymagających środowisk. EVPN może być używany jako warstwa kontrolna dla VXLAN, łącząc zalety enkapsulacji MAC-over-UDP z zaawansowanym zarządzaniem informacjami o adresach MAC. W perspektywie kilku lat EVPN prawdopodobnie zastąpi tradycyjne VPLS w sieciach operatorskich.
Monitorowanie stanu warstwy 2 w tunelach VPN jest kluczowe dla utrzymania stabilności sieci. Administator powinien regularnie sprawdzać liczniki błędów na interfejsach tuneli, takie jak liczba porzuconych ramek (Drops) czy błędów MTU. Gwałtowny wzrost tych wartości może sygnalizować problemy z konfiguracją lub przeciążenie łącza.
Szczególną uwagę należy zwrócić na liczbę ramek rozgłoszeniowych (Broadcast) przechodzących przez tunel. Gwałtowny wzrost ruchu broadcast może wskazywać na pętlę logiczną w sieci L2 lub obecność zainfekowanego urządzenia generującego nadmierny ruch. W takich sytuacjach konieczna jest szybka interwencja w celu zidentyfikowania źródła problemu.
Narzędzie /tool profile w RouterOS pozwala monitorować obciążenie procesora przez poszczególne procesy systemowe. Jeśli proces odpowiedzialny za mostkowanie (Bridge) lub enkapsulację tunelu (EoIP, VXLAN) zużywa nadmierną ilość CPU, może to oznaczać potrzebę optymalizacji konfiguracji lub modernizacji sprzętu. Regularny monitoring pozwala wykryć problemy, zanim wpłyną one na działanie sieci.
Zadanie praktyczne z konfiguracji tunelu EoIP pozwala ugruntować wiedzę teoretyczną w praktycznych umiejętnościach. Pierwszym krokiem jest zestawienie tunelu EoIP między dwoma routerami z użyciem jednakowego identyfikatora tunnel-id po obu stronach. Należy upewnić się, że adresy IP zdalnych routerów są wzajemnie osiągalne, a zapory sieciowe nie blokują protokołu GRE.
Po utworzeniu tunelu i dodaniu go do mostków sieciowych po obu stronach, należy przeprowadzić test ARP-Ping między urządzeniami końcowymi. Jeśli ARP-Ping działa, oznacza to, że ramki Ethernet są poprawnie przesyłane przez tunel. Kolejnym krokiem jest konfiguracja Bridge Filter w celu zablokowania niechcianego ruchu DHCP przez tunel, co zapobiega konfliktom adresacji.
Testowym wyzwaniem jest celowe wywołanie pętli sieciowej przez utworzenie drugiego tunelu EoIP i dodanie go do tego samego mostka. Pozwala to zaobserwować działanie protokołu RSTP, który powinien automatycznie zablokować jeden z portów, zapobiegając burzy rozgłoszeniowej. Po zakończeniu ćwiczeń należy usunąć konfigurację testową, aby nie powodować problemów w sieci produkcyjnej.
Technologie warstwy 2 w VPN stanowią potężne, ale wymagające narzędzie w arsenale administratora sieci. Umożliwiają one budowanie rozległych, transparentnych sieci Ethernet, które zachowują się jak jedna fizyczna sieć LAN, niezależnie od odległości między lokalizacjami. Kluczowe technologie takie jak EoIP, VXLAN, BCP czy OpenVPN TAP oferują różne podejścia do osiągnięcia tego samego celu.
Najważniejsze wnioski z omawianego materiału to konieczność starannego planowania przed wdrożeniem L2 VPN oraz świadomość zagrożeń związanych z pętlami i ruchem rozgłoszeniowym. Protokoły RSTP i filtrowanie na mostku są niezbędnymi narzędziami do utrzymania stabilności sieci. Przyszłość należy do rozwiązań takich jak VXLAN i EVPN, które łączą elastyczność L2 ze skalowalnością L3.
Końcowa rekomendacja dla administratorów jest jasna: używaj mostkowania L2 tylko wtedy, gdy jest to absolutnie konieczne. Dla typowych zastosowań korporacyjnych routing L3 w połączeniu z site-to-site VPN zapewnia lepszą wydajność, bezpieczeństwo i skalowalność. Technologie L2 VPN są jednak nieocenione w specyficznych scenariuszach, takich jak migracja maszyn wirtualnych, monitoring CCTV czy obsługa starszych protokołów nie-IP.