Prośby DHCP przeciekają przez VPN

Mam rozłożoną konfigurację do obsługi: 3 budynków poza zakładem z routerami opartymi na Tomato Firmware, łączących się z innym routerem opartym na Tomato jako konfiguracja VPN. Router serwera znajduje się również w naszej prywatnej sieci LAN (jako urządzenie brzegowe).

W naszej głównej sieci LAN mamy serwer DHCP działający na serwerze Linux, oferując 192.168.0.0/19 (tak, maska podsieci to 255.255.224.0!), Z wykluczonym oktetem 192.168.2.x / 24. W każdej witrynie każdy klient Tomato VPN (od teraz routery) powinien oferować swoim klientom adresy IP w określonym zakresie w podsieci 192.168.2.x. SiteA to 192.168.2.2-29 (router to .1), SiteB to 192.168.2.31-50 (router to .30), a SiteC to 192.168.2.52-80 (.51 to router). Komputery mogą łączyć się z naszym serwerem bez problemu.

Co jednak się dzieje, że nagle (kiedy wcześniej działało to doskonale), mam router z SiteA oferujący dzierżawę klientom w innych witrynach. Ponieważ znajdują się w tej samej ostatecznej sieci (192.168.0.0/19), mogą uzyskiwać dostęp do serwerów w naszej sieci LAN, ale nie do Internetu.

Jako tymczasowa poprawka, mogłem zdalnie uzyskać dostęp do komputerów w SiteB i SiteC i przypisać bramę domyślną do routerów w każdej lokalizacji. Nie jest to jednak dobra poprawka, ponieważ uniemożliwia innym pracownikom odwiedzanie witryny za pomocą laptopów lub tabletów i możliwość natychmiastowego połączenia.

Routery nie są kompilowane z obsługą ebtables zgodnie z zaleceniami w kilku innych wątkach. Ostatecznym celem jest, aby serwery DHCP oferowały tylko dzierżawy po stronie LAN własnych routerów.

Konfiguracja klienta VPN routera B.

Konfiguracja klienta VPN routera A ( Przekierowany ruch internetowy został pierwotnie wyłączony; został włączony powyżej tylko do testowania )

— Canadian Luke
źródło

Przepraszam, DHCP używa transmisji warstwy 2, więc nie można w ten sposób objąć serwera innym niż blokując żądania DHCP przekraczające VPN.

— Frank Thomas

@FrankThomas Jak mogłem to zrobić? Mam dostęp SSH do każdego routera, jeśli to pomaga

— Canadian Luke

Cóż, zaimplementowałbym zaporę ogniową na każdej bramie VPN i porzucił cały ruch UDP 67-68, który widzi przejście z VPN do locallan i odwrotnie. Wygląda na to, że twoje routery nie mają zainstalowanych modułów zapory, więc jest to trudniejsze.

— Frank Thomas

Czy klienci w lokalizacji B i C otrzymują przypisania IP z lokacji A lub tylko jednego z nich (B lub C)? Czy DHCP działa w innych witrynach, tzn. Jeśli próbowano ręcznie, czy router przekazuje adresy IP? Chodzi mi o to, że być może klienci idą do witryny A, ponieważ ich lokalny router nie odpowiedział lub nie odmówił żądania.

— Dr.Ping

I, jak już wspomniano, rozdzielanie witryn według podsieci jest właściwym sposobem i pozwala uniknąć wielu problemów

— Dr.Ping

Twoja VPN to TAP, zakładając, że OpenVPN jest podstawową technologią, oznacza to, że masz VPN warstwy 2. Oznacza to, że konfigurujesz wszystko tak, jakby wszystkie były fizycznie podłączone do tego samego przełącznika. Jeśli nie chcesz sieci warstwy 2, nie używaj TAP.

— Zoredache
źródło

Czy RUN (jedyna inna opcja) nadal pozwala na to, co chcę, gdzie klienci mogą widzieć się nawzajem przez każdą stronę? I masz dostęp do Internetu?

— Canadian Luke

Jeśli poprawnie skonfigurujesz trasy. Sieć tun jest lepszym rozwiązaniem, jest po prostu nieco bardziej skomplikowana. Czynnikiem komplikującym jest to, że nie jestem pewien, czy możesz zrobić to z pomidorem. Jestem całkowicie pewien, że bazowy OpenVPN to obsługuje. Trzeba by także trochę zmienić sieć, aby zdalne witryny były w osobnych podsieciach.

— Zoredache

I niestety nie mogę zmienić naszego schematu sieci na kilka następnych miesięcy :-(

— Canadian Luke

Ach, masz wtedy trudny problem. Nie wiem, co zasugerować. DHCP prawdopodobnie działa głównie dla ciebie, ponieważ klienci DHCP zazwyczaj akceptują najszybszą odpowiedź, która zwykle pochodzi z fizycznie najbliższego serwera DHCP.

— Zoredache