VLAN-y klientów czy tagowany trunk: wybierz właściwy tryb OpenVPN

Przychodzą dwa żądania o niemal identycznym brzmieniu: umieść każdego klienta VPN w wybranym VLAN-ie albo przenieś istniejący trunk VLAN przez VPN. To dwa różne produkty. Wbudowany tryb OpenVPN świadomy VLAN-ów to model przełącznika dla pierwszego żądania i nie jest synonimem przezroczystego transportu tagów. Zły wybór daje projekt, który wygląda na skonfigurowany, a po cichu odrzuca ramki, na których ci zależało.

Co właściwie buduje tryb świadomy VLAN-ów

Gdy vlan-tagging jest włączone we wdrożeniu TAP tylko dla serwera, demon modeluje swoje urządzenie TAP i każdego podłączonego klienta jako porty wewnętrznego przełącznika. Porty klientów są bez tagu, a ich powiązanie z VLAN-em jest ustawiane na serwerze przez kontekst vlan-pvid dla każdego klienta, a nie przez to, co wysyła klient. W tym jest cały sens modelu: członkostwo to decyzja po stronie serwera o uwierzytelnionym peera. Nic w profilu klienta nie musi wiedzieć, do którego VLAN-u należy.

Strona TAP serwera otrzymuje własną politykę akceptacji tagowanych lub nietagowanych ramek przez vlan-accept. Przekazywanie wewnątrz tego przełącznika odbywa się tylko między zgodnymi VID-ami, także gdy ustawiono client-to-client, więc dwaj klienci w różnych VLAN-ach nie mogą sięgnąć się nawzajem przez serwer, choć obaj są do niego podłączeni.

Ten model to model portu dostępowego. Ramki opuszczające klienta są bez tagu, a powiązanie narzuca serwer na podstawie tożsamości. Proszenie laptopa, by sam tagował swój ruch, oznacza proszenie o inny projekt.

Przydziały muszą podążać za uwierzytelnioną tożsamością klienta, a nie za wartością, którą klient o sobie podaje. Pominięty przydział nie jest też stanem kwarantanny: klient trafia na domyślny PVID, więc brakujący wpis ccd to cicha decyzja polityki, a nie neutralna.

Czego zamiast tego wymaga przezroczysty trunk

Przenoszenie już tagowanych ramek od końca do końca zaczyna się od wyłączenia przetwarzania świadomego VLAN-ów. Model przełącznika i zachowanie tagów to alternatywy, a włączenie obu prosi jedną funkcję o wykonywanie pracy drugiej.

Wyłączenie to dopiero początek. Most na każdym końcu i fizyczne porty przełącznika muszą się zgodzić, które VLAN-y są dozwolone, który tag jest natywny i jak traktowane są ramki bez tagu. Rozszerzenie nieograniczonego trunku odsłania znacznie więcej domen rozgłoszeniowych niż te dwie, które chciałeś połączyć.

Rozmiar ramki wymaga własnego budżetu. Tagowana ramka Ethernet plus enkapsulacja jest większa niż liczba ładunku, którą ludzie kopiują z poradnika, a MTU odpowiednie dla tunelu routowanego nie dowodzi, że ścieżka trunku działa.

Trzy warunki, które decydują o odpowiedzi

Po pierwsze, czy platforma klienta w ogóle obsługuje TAP? Android i iOS nie, a wsparcie macOS jest ograniczone, więc flota użytkowników mobilnych wyklucza oba projekty TAP, niezależnie od tego, jak ułożone są VLAN-y. Sprawdź flotę, zanim zaprojektujesz topologię, bo ten warunek jest jedynym, którego nie da się obejść. To także warunek najczęściej odkrywany już po zakończeniu prac przy przełączniku.

Po drugie, kto przydziela VLAN? Jeśli odpowiedź brzmi «serwer, na podstawie tego, kto się uwierzytelnił», pasuje model przełącznika. Jeśli odpowiedź brzmi «istniejąca infrastruktura przełączników, z tagami, które już istnieją», potrzebujesz projektu trunku.

Po trzecie, jaka część sieci ma być osiągalna? Model przełącznika z założenia trzyma każdego klienta w jednym VLAN-ie. Projekt trunku to most, a źle skonfigurowany most łączy domeny rozgłoszeniowe, które miały pozostać rozdzielone.

Sprawdzenie dokonanego wyboru

Podłącz jednego klienta, który powinien być w dozwolonym VLAN-ie, i jednego, który nie powinien, a potem testuj z rzeczywistego końca, a nie z samego serwera. Osiągalność od strony serwera dowodzi, że most lub przełącznik istnieje; nie dowodzi, do którego VLAN-u trafił klient.

ip -d link show tap0
bridge vlan show

Na serwerze druga komenda pokazuje członkostwo VLAN każdego portu mostu, w tym czy port jest tagowany. Porównaj to z zamierzonym przydziałem, zanim zaczniesz debugować cokolwiek powyżej drugiej warstwy.

Zapisz, który z dwóch projektów wykorzystuje wdrożenie. Notatka «świadomy VLAN-ów» jest niejednoznaczna, a następny inżynier przyjmie ten, którego nauczył się pierwszy. Dokumentacja VLAN OpenVPNdefiniuje zachowanie przełącznika i kontekst dla poszczególnych klientów, i jest najkrótszą drogą do potwierdzenia, który model uruchamiasz.