Dlaczego host LAN wysyła ARP dla adresu klienta OpenVPN

Problemy z osiągalnością między hostem LAN a klientem VPN często prowadzą z powrotem do samego planu adresacji. Nadaj temu hostowi interfejs w 10.0.100.0/22, a będzie traktował każdy adres od 10.0.100.0 do 10.0.103.255 jako bezpośrednio podłączony, łącznie z pulą klientów cicho umieszczoną w 10.0.101.0/24. Odpowiedź nigdy nie trafia do routera, ponieważ z punktu widzenia hosta żaden router nie bierze udziału. Pakiet jest adresowany do sąsiada i wywoływany na łączu.

Ten mechanizm stoi za całą rodziną zgłoszeń: tunel jest włączony, serwer ma trasę, a host LAN nadal nie może osiągnąć klienta.

Prefiks /22, który połyka /24

Czytaj prefiks jako zakres, nie jako ciąg znaków. Prefiks /22 zawiera 1024 adresy, a 10.0.100.0/22 obejmuje od 10.0.100.0 do 10.0.103.255, więc pula w 10.0.101.0/24 leży całkowicie w jego wnętrzu. Błąd przechodzi przegląd, ponieważ pierwsze oktety puli wyglądają inaczej niż pierwsze oktety LAN, a tylko trzeci oktet ujawnia zagnieżdżenie. Zapisz oba zakresy liczbowo, zanim uznasz je za rozłączne.

To samo zagnieżdżenie może wystąpić w drugą stronę. Pula, która wygląda na wolną, bo nic jej teraz nie używa, może jednak wpaść w prefiks ogłaszany przez jakiś router oddziału, a plan adresacji jest jedynym dokumentem, który to pokazuje.

Połączenie bezpośrednie oznacza ARP, nie routing

Gdy host z interfejsem /22 wysyła do 10.0.101.25, jądro porównuje cel z prefiksem interfejsu i znajduje dopasowanie. Pakiet staje się rozwiązywaniem sąsiada zamiast pakietu routowanego, a w Ethernete rozwiązywanie sąsiada to żądanie ARP dla tego adresu. Jeśli adres należy do klienta VPN za routowaną bramą, żaden host w LAN go nie posiada, więc żądanie pozostaje bez odpowiedzi, a pakiety są odrzucane. Tunel nie jest winny, a klient nigdy nie widzi ruchu.

Dlatego awaria wygląda asymetrycznie i czasem jest przerywana. Host VPN często dociera do LAN, bo jego własne trasy wskazują właściwy kierunek, podczas gdy host LAN nie może odpowiedzieć, a wszystko, co buforuje nieaktualny wpis ARP, sprawia, że objaw migocze.

TUN, TAP i co przenosi każde z nich

Urządzenie TUN przenosi pakiety IP, a urządzenie TAP przenosi ramki Ethernet. Routowane łącze TUN nie musi przenosić ARP, aby zapewnić osiągalność IP, i właśnie dlatego nieodpowiedziane żądanie powyżej jest oczekiwane, a nie zepsute. TAP z celowo ustawionym mostem może rozszerzyć domenę rozgłoszeniową i sprawić, że ARP zadziała, ale zmienia to, co widzi klient, wymaga punktów końcowych obsługujących to samo ramkowanie i jest przeprojektowaniem modelu sieci, a nie naprawą nakładającego się prefiksu. Przełączenie wdrożenia routowanego na TAP, aby wyleczyć błąd planu adresacji, zamienia mały problem na większy.

Zanotuj, gdzie pojawiło się żądanie ARP i który system je wysłał, zanim wyciągniesz wnioski. Nadawca mówi ci, co sądzi o celu, a nie co robi tunel.

Zaprojektuj pulę, która nie może się nakładać

Wybierz pulę poza każdym podłączonym prefiksem i każdym ogłaszanym prefiksem oddziału, a następnie dodaj trasy, które czynią ją osiągalną w obu kierunkach. Zakres taki jak 10.8.0.0/24 w nieużywanej części planu jest łatwy do przemyślenia, a LAN, który musi do niego dotrzeć, otrzymuje trasę statyczną wskazującą serwer VPN. Zmieniaj razem alokację, ogłaszane trasy, dozwolone adresy źródłowe i reguły zapory, ponieważ opisują jeden projekt, a nie cztery ustawienia.

NAT źródłowy na serwerze może ukryć pulę za adresem routowalnym z LAN i jest legalnym narzędziem migracji. Przepisuje też źródło, więc LAN traci możliwość przypisywania połączeń do poszczególnych klientów i stosowania reguł dla klienta.

Do odbioru użyj rzeczywiście przypisanego adresu prawdziwego klienta i prawdziwego żądania aplikacji z hosta LAN, a następnie potwierdź, że odpowiedź podąża za planowaną bramą, a nie za łączem.