Klient VPN z adresem LAN nie jest w sieci LAN

Klient łączy się, otrzymuje 10.50.0.200 i nie może dotrzeć do serwera pod 10.50.0.20, mimo że oba numery leżą w tej samej /24. Przekonanie stojące za tą konfiguracją jest takie, że adres z prefiksu LAN czyni klienta częścią LAN. Nie czyni. Klient jest na łączu punkt-punkt, serwer uważa cel za lokalny, a brakującym elementem jest odpowiedź sąsiada, której nikt nie wysyła.

Mit: ten sam prefiks oznacza ten sam segment

Prefiks adresu mówi hostowi, które cele może osiągnąć bezpośrednio, a które wymagają routera. Nie mówi hostowi, jak cel jest fizycznie podłączony, i z pewnością nie gwarantuje, że cel odpowie na żądanie warstwy łącza. To różne pytania, na które odpowiadają różne tablice na hoście. Maska odpowiada na pierwsze, a tablica sąsiadów na drugie, i tylko pierwsze jest pod twoją kontrolą po stronie VPN.

Gdy serwer wysyła do 10.50.0.200, porównuje cel z własną maską, uznaje adres za on-link i pyta lokalny segment o adres sprzętowy, który do niego należy. To żądanie wychodzi przez interfejs Ethernet, a klienta VPN tam nie ma, by je usłyszeć.

Nic w konfiguracji klienta nie może tego naprawić z jego strony. Ścieżka odpowiedzi zależy od tego, czy urządzenie w LAN odpowie w imieniu klienta, czy klient będzie miał adres, którego serwer nie uznaje za lokalny.

Co lokalny host naprawdę robi z adresem

Zachowanie łatwo zaobserwować i warto to zrobić, zanim cokolwiek zmienisz. Spójrz na tablicę sąsiadów na hoście LAN po próbie dotarcia do klienta: niekompletny lub nieudany wpis to cała diagnoza w jednym wierszu. Ten wiersz mówi też, że usterka jest lokalna dla segmentu, a nie gdzieś wewnątrz tunelu.

ip neigh show 10.50.0.200
ip route get 10.50.0.200
arping -I eth0 -c 3 10.50.0.200

Wyszukiwanie trasy zgłosi cel jako on-link przez interfejs Ethernet, i to jest właśnie problem. Jeśli wpis sąsiada pozostaje niekompletny, dopóki sesja VPN działa, potwierdziłeś, że brakującym elementem jest rozwiązanie na warstwie łącza, a nie routing czy polityka firewalla.

Wykonaj tę samą kontrolę z hosta w innej podsieci i porównaj. Host, który dociera do klienta przez router, w ogóle nie potrzebuje wpisu sąsiada, i ta różnica jest decyzją projektową w miniaturze.

Jak proxy ARP zapewnia następny skok

proxy ARP sprawia, że brama odpowiada na żądanie warstwy łącza w imieniu celu, do którego może dotrzeć przez inny interfejs. Host LAN otrzymuje adres sprzętowy, wysyła ramkę do bramy, a brama przekazuje pakiet do sesji VPN. Z punktu widzenia hosta klient po prostu wygląda, jakby był za bramą. W konfiguracji klienta nic się nie zmienia.

Dokumentacja RouterOS dotycząca ARP firmy MikroTik opisuje takie użycie dla klientów dial-in, którzy pożyczają przestrzeń adresową podłączonej sieci LAN. Mechanizm jest naprawą rozwiązywania sąsiadów i działa, ponieważ brama naprawdę znajduje się na obu ścieżkach.

To nie to samo co mostkowanie klienta do LAN. Brama nadal musi przekazać pakiet do właściwej aktywnej sesji, a jej routing i polityka firewalla nadal muszą zezwalać na usługę. proxy ARP zmienia to, kto odpowiada na żądanie sąsiada, nie to, komu wolno mówić.

Czytaj uważnie nazwy trybów platformy. RouterOS rozróżnia proxy-arp i local-proxy-arp, a drugi obsługuje ruch wchodzący i wychodzący przez ten sam interfejs. To nie są wymienne zapisy, a włączanie obu bez rozróżnienia nie jest skrótem.

Czego proxy ARP ci nie daje

Nie zapewnia wykrywania przez broadcast ani multicast. Klient, który musi znaleźć usługę przez broadcast, nadal poniesie porażkę, ponieważ brama przekazuje unicast do sesji i nie czyni klienta członkiem domeny broadcast sieci LAN. Protokoły wykrywania oparte na broadcast są częstym źródłem zgłoszeń, że działa to dla jednej rzeczy, a nie dla innej, w projektach z pożyczonymi adresami.

Nie rezerwuje adresu. Jeśli pożyczony numer znajduje się także w puli DHCP lub w przypisaniu statycznym, dwa urządzenia mogą skończyć z tym samym adresem, a wynikowe zachowanie zależy od czasu. Udane logowanie nie jest rezerwacją.

I nie usuwa potrzeby uzgodnienia z właścicielem sieci LAN. Wpis proxy ARP, który zaskakuje właściciela planu adresowego, jest incydentem wsparcia czekającym na spokojny tydzień.

Porównanie z osobną pulą routowaną

Alternatywą jest danie klientom VPN własnego prefiksu i pozwolenie hostom LAN na routowanie do niego. Wtedy serwer wysyła odpowiedzi off-link do swojej bramy, brama routuje prefiks do punktu końcowego VPN, a w segmencie LAN w ogóle nie potrzeba rozwiązywania sąsiadów. To mniej ruchomych części niż pożyczony adres plus odpowiedź proxy.

Taki projekt jest łatwiejszy do przemyślenia i łatwiejszy do audytu, ponieważ zakres klientów jest widocznie oddzielony od zakresu LAN. Kosztuje trasę, ścieżkę powrotną i regułę dostępu, czyli te same rzeczy, których projekt z proxy ARP potrzebuje w mniej oczywistym miejscu.

Wybieraj między modelami świadomie, a nie przypadkiem. proxy ARP naprawia jedną konkretną relację; routowana pula usuwa potrzebę tej naprawy. Zapisz, co wybrałeś i dlaczego, a następna osoba nie będzie musiała odkrywać tego od nowa z nieudanego wpisu sąsiada.