Dlaczego twój czujnik VPN nigdy nie widzi znacznika VLAN oddziału
Routowany tunel odtwarza pakiety, a nie ramki, które je dostarczyły. Cztery kontrole: typ interfejsu, położenie czujnika, kontekst źródła i ścieżka odpowiedzi.
Czujnik po stronie VPN widzi dwa VLAN-y oddziału jako zwykły ruch IP, a znacznik, który identyfikował każdy oddział na jego własnym kablu, zniknął. Właśnie to robi routowany tunel: odtwarza pakiety, a nie ramki Ethernet, które je dostarczyły. Czy brakujący znacznik ma znaczenie, zależy całkowicie od pytania, które zadajesz czujnikowi. Wykonaj cztery kontrole poniżej po kolei, a będziesz wiedzieć, który punkt obserwacji może na nie odpowiedzieć.
Najpierw: ustal, co odtwarza twój tunel
Interfejs TUN przenosi pakiety IP, więc nagłówek VLAN ramki oddziału zatrzymuje się na routerze, który wepchnął ruch do tunelu. Interfejs TAP przenosi ramki Ethernet, co oznacza, że znaczniki mogą przetrwać, gdy most i reguły dopuszczania VLAN je przepuszczą. Przeczytaj typ interfejsu, zanim zaczniesz rozważać, co powinien zawierać zrzut.
Żaden z wyborów nie jest defektem. Oba projekty odpowiadają na różne pytania i zostawiają znacznik w różnych miejscach.
Sprawdź interfejs sam, zamiast wnioskować go z nazwy produktu. Szczegóły połączenia podają typ urządzenia i pokazują obowiązujące flagi, a zrzut wykonany na urządzeniu TUN nie dostanie nagłówka Ethernet tylko dlatego, że o niego poprosiłeś. Jeśli w zrzucie TUN mimo to pojawią się znaczniki, prawie na pewno czytasz inny interfejs albo tunel, który przenosi ramki wewnątrz swojej ładowności. Zanotuj, który przypadek u ciebie zachodzi, zanim przejdziesz dalej.
Po drugie: umieść czujnik tam, gdzie obiekt jeszcze istnieje
Trzy pozycje pokrywają większość routowanych projektów: segment Ethernet oddziału, sieć zewnętrzna między końcami tunelu i ścieżka po przetworzeniu tunelu. Każda widzi inny obiekt, a znacznik istnieje tylko w pierwszej. Wybór pozycji czujnika to decyzja o tym, jakiego obiektu potrzebuje polityka, a nie kwestia wygody.
| Observation point | What is actually there | Question it can answer |
|---|---|---|
| Branch Ethernet segment | Tagged frames on the local wire | Which VLAN carried this frame here |
| Outer tunnel network | The protected carrier between endpoints | Which endpoints are exchanging traffic |
| After tunnel processing | Recovered IP packets | Which branch prefix the packet claims |
Zadaj pytanie polityki w takich słowach, na które tabela potrafi odpowiedzieć, a zwykle rozwiązuje się samo. Jeśli reguła musi wiedzieć, z którego oddziału przyszedł pakiet, mapowanie prefiksów niżej może wystarczyć, ale tylko dopóki to mapowanie jest dokładne i jednoznaczne. Jeśli reguła musi wiedzieć, na który port dotarła ramka, potrzebujesz pierwszej pozycji, bo nic niżej nie potrafi tego odtworzyć. Czujniki umieszczane z przyzwyczajenia, a nie z pytania, są powodem, dla którego zespoły w końcu żądają pola, którego projekt nigdy nie przenosił.
Tunel przenoszący Ethernet to inny projekt i wymaga własnej kontroli tego, co końce zachowują lub przepisują. Sam wybór TAP wciąż nie definiuje mostu, reguł dopuszczania VLAN ani polityki inspekcji.
Po trzecie: zasłuż na kontekst źródła, zamiast mu ufać
Jeden zakres adresów na oddział to zwykły zamiennik tożsamości VLAN i działa tylko dopóki mapowanie pozostaje jeden do jednego. Nakładające się prefiksy, tłumaczenie i wspólna brama każdy z osobna łamie to założenie w sposób, który wygląda jak problem jakości danych, a nie projektu. Zapisz mapowanie wraz z jego granicami i powiedz, co dzieje się z pakietem pasującym do dwóch wierszy. Prefiks występujący w dwóch oddziałach powinien być błędem, który wykrywasz, a nie rzutem monetą, który akceptujesz.
Kontekst podany przez klienta nie jest dowodem członkostwa. To twierdzenie, a jego miejsce jest w innej kolumnie.
Tam, gdzie różnica ma znaczenie, użyj danych powiązań, które kontrolujesz: która instancja tunelu przyjęła połączenie, na który interfejs przyszły pakiety, co lokalna tablica tras mówi o tym pecu. Etykieta podana przez klienta to użyteczna wskazówka i bezużyteczne wejście autoryzacji. Jeśli czujnik nie potrafi ustalić powiązania po swojej stronie, polityka potrzebuje szerszej reguły, a nie pewnej siebie zgadywanki.
Po czwarte: potwierdź ścieżkę odpowiedzi i to, co pomija odszyfrowanie
Czujnik widzący tylko jeden kierunek nadal może wyglądać zdrowo, bo żądania wciąż przychodzą zgodnie z planem. Sprawdź ścieżkę odpowiedzi wprost i sprawdź ją dla tego samego przepływu, a nie dla ogólnej osiągalności. Widoczność półdupleksowa staje się cichą luką w każdym wniosku opartym na stanie, który z niej wyciągasz.
Odtworzenie wewnętrznego ruchu IP też nie jest tym samym, co widzenie aplikacji w jego wnętrzu, bo TLS przenoszony przez tunel pozostaje TLS.
ip -d link show tun0
tcpdump -i tun0 -n -e -c 5Te dwa polecenia odpowiadają na pytanie o interfejs i pokazują, co zrzut naprawdę zawiera, co jest szybsze niż spieranie się o architekturę. Zastąp nazwę interfejsu, której używa twój projekt, i uruchom zrzut, gdy przepływ, który cię interesuje, jest aktywny. Gdy na urządzeniu TUN nie pojawia się żaden znacznik, ustalenie brzmi: projekt routował, a nie mostkował, a nie że czujnik zgubił dane. Następnie albo przenieś czujnik na pozycję, która widzi znacznik, albo przepisz regułę w słowach, które obecna pozycja potrafi obsłużyć.