VPN gościa na ESXi: routing czy most — zdecyduj przed grupą portów
Routowany TUN wymaga tras powrotnych; mostkowany TAP wymaga dostępu warstwy 2 i szerszej polityki grupy portów. Ustal rolę, zanim rozszerzysz tryb promiscuous.
Routuj pakiety albo rozszerz domenę Ethernet: zmiana grupy portów następuje po tym wyborze. Z punktu widzenia aplikacji z adresem prywatnym wyniki mogą wyglądać identycznie, podczas gdy wymagania hipervisora są zupełnie inne. Dlatego najpierw rozszerza się grupę portów, a pytanie projektowe rozstrzyga się później, zwykle po burzy broadcastowej. Przejdź te kontrole po kolei i zatrzymaj się, dopóki wymaganie jest niejasne, bo żadne ustawienie grupy portów nie naprawi projektu, którego nigdy nie wybrano.
Decyzja należy do właściciela usługi; konfiguracja hipervisora powinna ją wdrażać, a nie przypadkiem ją określać.
Sprawdź, czego naprawdę potrzebuje drugi koniec
Wypisz usługi, do których muszą dotrzeć zdalni klienci, oraz protokoły, których używają. Jeśli lista to kilka usług TCP na znanych prefiksach, routing to pokrywa. Jeśli coś naprawdę wymaga sąsiedztwa warstwy 2 — wykrywanie zależne od broadcastu, protokoły nie-IP, urządzenie, które nie akceptuje bramy — routing tego nie udaje i trzeba to powiedzieć wcześnie. Bądź szczery co do pozycji nie-IP na tej liście, bo właśnie tam routowany projekt po tygodniu po cichu zawodzi.
Potem sprawdź pulę klientów. Projekt routowany wymaga zakresu adresów i jawnej trasy powrotnej po drugiej stronie; projekt mostkowany wymaga, by rozszerzona domena Ethernet miała przydział adresów i izolację. Cokolwiek wybierzesz, ktoś spoza tej VM musi to zaakceptować.
Czego każdy projekt wymaga od sieci wirtualnej
Oba projekty różnią się tym, co sieć wirtualna musi znieść, a tabela to najkrótszy sposób, by to zobaczyć:
| Projekt | Rola po stronie gościa | Co sieć wirtualna musi pomieścić | Tryb awarii przy złym wyborze |
|---|---|---|---|
| Routowany TUN | Router między osobnymi prefiksami | Routowana pula klientów plus ścieżki powrotne po drugiej stronie | Klienci docierają do bramy i nigdy nie docierają do usługi za nią |
| Mostkowany TAP | Most warstwy 2 dla klientów, którzy się przyłączają | Dodatkowe tożsamości Ethernet, ruch broadcastowy i reguły VLAN | vSwitch odrzuca ramki albo projekt wymaga trybu promiscuous, którego nikt nie zatwierdził |
Routing zostawia domenę broadcastu tam, gdzie jest, i daje naturalne miejsce na ograniczenie, które usługi przechodzą przez bramę. Mostkowanie przesuwa granicę: klienci stają się uczestnikami rozszerzonej domeny Ethernet, a przydział adresów, izolacja i wszelka polityka warstwy 2 dotyczą teraz ich. Zapisz wybrany wiersz w rejestrze zmian. Zdanie typu „routowany TUN, pula klientów 10.90.0.0/24, trasa powrotna na rdzeniu” nie pozwala następnemu inżynierowi ponownie roztrząsać projektu na podstawie ustawień grupy portów.
Kto powinien widzieć czyje ramki
Zadaj właścicielowi platformy jedno pytanie, zanim dotkniesz grupy portów: czy projekt wymaga, by ta VM odbierała ramki adresowane do innych uczestników? Jeśli odpowiedź brzmi nie, nic w tej sekcji nie ma zastosowania, bo routowany TUN nigdy nie potrzebuje tej widoczności. Jeśli odpowiedź brzmi tak, to wskazówki Broadcomu dotyczące trybu promiscuous są lekturą, która się liczy: wyjaśniają, jak dużo więcej vSwitch widzi VM, i zalecają ograniczenie tej polityki do jednej grupy portów.
Traktuj to jako kontrolę wymagania, nie jako pozwolenie. Włącz ustawienie dla jednego dedykowanego przyłącza, gdy potrzeba mostkowania jest zapisana, a wszędzie indziej pozostaw je wyłączone. Szeroki trunk VLAN skopiowany z innego przykładu mostu to część, o której nikt nie pamięta, by ją usunąć, a projekt z jednym VLAN powinien pozostać z jednym VLAN.
Zapisz, która grupa portów się zmieniła i dlaczego, w tym samym miejscu, gdzie zapisano wiersz projektu. To zestawienie umożliwia następny audyt.
Utrzymuj obiekty gościa jawnie
W Linuxie przynależność do mostu i własność adresu to osobne obiekty, a ich mieszanie powoduje mylący półdziałający stan. Przydzielaj adresy interfejsowi mostu albo routowanemu tunelowi, nie obu stronom tej samej ścieżki, a porty członkowskie trzymaj bez konfiguracji IP.
Unikaj umieszczania jednej podsieci niezależnie na routowanym TUN i na niepowiązanym interfejsie Ethernet. Taka konfiguracja tworzy dwie ścieżki do tego samego prefiksu, asymetryczne odpowiedzi i wątek pomocy o flappingu, który nie wspomina żadnej ze ścieżek. Jeśli gość hostuje też kontenery lub lokalny hipervisor, sprawdź, czy nie mostkują już do tego samego uplinku. Dwa mosty na jednej NIC to projekt, a nie wypadek, który chcesz odkryć w oknie zmian.
Potwierdź ścieżką pakietu, nie pingiem
Zweryfikuj rzeczywistą ścieżkę, nie tylko osiągalność. Od klienta potwierdź, który adres źródłowy dociera do zdalnej usługi, a potem że odpowiedź wraca tą samą drogą. Na gościu sprawdź liczniki przekazywania dla konkretnego przepływu, a na grupie portów potwierdź, że nie włączono dodatkowej widoczności ponad to, czego wymaga wybrany projekt.
Na koniec przetestuj kierunek awarii. Zatrzymaj tunel albo odłącz klienta i sprawdź, czy ruch nie spada po cichu na routowaną ścieżkę, którą uważałeś za nieużywaną, bo właśnie ten upadek sprawia, że mostkowany projekt po cichu staje się niezamierzonym routerem.