Czy dwie lokalizacje potrzebują tych samych VLAN ID dla VPN między lokalizacjami?

Te same numery VLAN w dwóch biurach wydają się czymś, co powinno pomóc tunelowi między lokalizacjami, a nie zmieniają niczego w tym, co tunel przenosi. VLAN ID oznacza domenę rozgłoszeniową Ethernet wewnątrz jednego budynku; tunel przekazuje pakiety IP między bramami. Dwie lokalizacje mogą używać zupełnie innej numeracji VLAN i nadal routować do siebie, a dwie lokalizacje mogą używać identycznej numeracji VLAN i nadal nie móc się osiągnąć. Zmienną decydującą o osiągalności jest plan adresacji.

Mit: te same VLAN ID na obu końcach

Przekonanie bierze się z rozsądnego miejsca. Wewnątrz jednego budynku dwa porty w tej samej VLAN mogą się komunikować, a dwa porty w różnych VLAN nie, więc numer VLAN wygląda jak to, co daje łączność. Przez routowany tunel nie ma wspólnego segmentu Ethernet, który mógłby opisać tag, a bramy nigdy nie wymieniają etykiet VLAN.

Tunel potrzebuje pary nienakładających się zakresów adresów i polityki, która zezwala na ruch między nimi. Zmień VLAN w dowolnym biurze, a tunel nadal działa, bo nic w konfiguracji tunelu go nie wskazywało. To jest test, który rozstrzyga spór: przenumeruj VLAN, zostaw adresy bez zmian i obserwuj, czy tunel się utrzyma.

Odwrotny test jest równie pouczający. Daj obu biurom tę samą podsieć, a żadna liczba zgodnych numerów VLAN nie uczyni adresu jednoznacznym.

Co tunel faktycznie przenosi

IPsec chroni pakiety IP zgodnie z polityką wyrażoną w adresach, protokołach i portach. Architektura IPsec opisuje te selektory na warstwie IP, która jest kilka warstw ponad wszystkim, co opisuje tag przełącznika. Gdy pakiet wchodzi do tunelu, opuścił już VLAN; tag został zużyty przez lokalny przełącznik.

Projekty oparte na polityce i oparte na trasach różnią się tym, jak wybierają tunel, a nie tym, co mogą przenosić. Partner oparty na polityce dopasowuje selektory ruchu i wysyła pasujące pakiety do tunelu. Partner oparty na trasach routuje ruch na interfejsie tunelu i pozostawia decyzję tabeli routingu. Oba nadal negocjują zakres ochrony, więc trasa wskazująca na tunel nie rozszerza tego, co partnerzy zgodzili się chronić.

Ta różnica wyjaśnia częstą połowiczną porażkę: trasa istnieje, pakiety wchodzą do tunelu, a druga strona je odrzuca, bo wynegocjowane selektory nigdy nie obejmowały tego prefiksu. Czytanie zainstalowanych polityk pokazuje, który zakres faktycznie wszedł w życie.

ip xfrm policy
ip route show
swanctl --list-sas

Nakładanie, które naprawdę psuje

Dwa biura z różnymi podsieciami czysto routują się przez tunel, a ich numery VLAN są nieistotne. Dwa biura z tą samą podsiecią nie, bo żądanie danego adresu ma dwa możliwe znaczenia, a tabela routingu może wybrać tylko jedno. Przenumerowanie jednej lokalizacji to czyste rozwiązanie i zwykle jest tańsze niż alternatywy, gdy policzy się zmiany DNS i zapory.

Gdy przenumerowanie jest niemożliwe, celowy projekt tłumaczenia może przedstawić każdej stronie odrębne widoki adresów. To oznacza mapowanie jeden do jednego, pasujące selektory, wpisy DNS odzwierciedlające przetłumaczony widok i routing powrotny, który przetrwa przepisanie. To obsługiwany projekt z realnymi kosztami operacyjnymi i nie jest to, co robi zmiana VLAN ID.

Te same numery VLAN na obu końcach są czasem przypadkiem wspólnego szablonu, a traktowanie tego przypadku jako przyczyny działającego tunelu prowadzi do niewłaściwej zmiany, gdy coś później się zepsuje.

Jedno zadanie na warstwę, spisane

Lokalny przełącznik decyduje, które porty dzielą domenę rozgłoszeniową, a jego numeracja VLAN jest lokalną księgowością, której żadna inna lokalizacja nie musi znać. Brama uwierzytelnia partnera i egzekwuje wynegocjowany zakres ochrony. Tabela routingu decyduje, dokąd dalej trafi odszyfrowany pakiet, a polityka dostępu decyduje, czy ten pakiet w ogóle powinien był być dozwolony.

Rozdzielenie tych zadań jest tym, co czyni zmiany bezpiecznymi. Przenumerowanie VLAN w jednym biurze dotyka lokalnego przełącznika, zakresu DHCP i być może strefy zapory, a nie dotyka tunelu. Zmiana prefiksu dotyka selektorów tunelu, tras po obu stronach i polityki dostępu, a nie dotyka tagów przełącznika.

Trasy powrotne, prywatny DNS i wymagania dotyczące tożsamości aplikacji to znów osobne zadania i żadne z nich nie powstaje przez skopiowanie numeru VLAN z drugiej lokalizacji. Dokument projektowy wymieniający osiągalne prefiksy i dozwolone usługi przetrwa wymianę przełącznika; ten wymieniający numery VLAN nie przetrwa.

Potwierdź lokalny obraz narzędziami bridge, zanim przyjmiesz, że tag dociera do tunelu.

bridge vlan show
ip -br addr
ip route get 10.62.0.20

Gdy rozszerzenie layer-2 jest prawdziwym wymaganiem

Niektóre projekty naprawdę potrzebują zachowania Ethernet między lokalizacjami: starsza aplikacja opierająca się na wykrywaniu rozgłoszeniowym, migracja, która musi zachować adres podczas przenoszenia maszyny, albo protokół zawierający założenia layer-2. Takie przypadki wymagają overlayu lub usługi mostkowanej, która przenosi ramki, a wtedy przynależność do VLAN, zapobieganie pętlom i obsługa awarii stają się sprawami od końca do końca.

To znacznie większa domena awarii i powinien to być świadomy wybór, a nie przypadkowy wynik próby uruchomienia udostępniania plików. Zwykły serwer plików, baza danych lub aplikacja webowa potrzebują autoryzowanej ścieżki IP i będą szczęśliwsze bez rozciągniętej domeny rozgłoszeniowej pod spodem.

Zapisz kontrakt VPN jako osiągalne prefiksy plus dozwolone usługi, a tag VLAN rejestruj tylko tam, gdzie potrzebują go lokalne operacje. Wtedy każde biuro może przenumerować własne przełączanie, nie zamieniając każdej zmiany w przeprojektowanie tunelu.