Brama VPN na Raspberry Pi: jedna karta sieciowa albo osobny port klienta

Masz jednego Pi, jeden działający wychodzący profil VPN i dwa urządzenia, które powinny docierać do internetu przez niego. Pytanie, które rozstrzyga całą budowę, nie brzmi, którego poradnika się trzymać, lecz ile odseparowania potrzebujesz. Jeden port pozwala Pi stać obok tych urządzeń w sieci LAN routera i działać jako dodatkowa brama; drugi port pozwala umieścić je w segmencie, w którym Pi jest jedynym wyjściem. Wszystko po tym wyborze — DHCP, zasięg zapory, DNS, przypadek awarii — wynika z niego.

Czym oba układy naprawdę się różnią

Oba projekty routują. Różnica polega na tym, kto jeszcze stoi na kablu i co się dzieje, gdy twoja polityka jest błędna.

Odseparowanie jest prawdziwą osią. Układ A jest doradczy: urządzenie, które ignoruje bramę podaną przez DHCP i wybiera router, nadal działa, ale bez szyfrowania. Układ B jest wymuszany przez topologię, bo nie ma innego następnego skoku do wyboru.

Układ A: Pi jako dodatkowa brama w istniejącej sieci LAN

Załóżmy, że router ISP to 192.168.50.1, Pi to 192.168.50.2, a wybrane klienty wskazują na Pi. Ważne jest to, że dwa różne strumienie pakietów dzielą jeden kabel. Wewnętrzny pakiet klienta dociera do Pi i musi wyjść przez tunel; własny zaszyfrowany pakiet Pi do partnera VPN musi wyjść tym samym kablem do routera. Poruszają się w przeciwnych kierunkach po tym samym interfejsie i wymagają innego traktowania.

Nadaj Pi adres przez zainstalowanego menedżera sieci, a nie przez stary przepis z plikiem interfejsu, który walczy z nim o urządzenie. Potem ustaw klienty: statyczną bramę na jednym urządzeniu albo rezerwację DHCP, która rozdaje 192.168.50.2 jako router. Nie zmieniaj całego zakresu DHCP routera z powodu dwóch urządzeń i nie zakładaj, że klient respektuje tę opcję — sprawdź to.

Słabość jest strukturalna, a nie do naprawienia. Każdy klient w tym segmencie może wskazać 192.168.50.1 i wyjść jawnym tekstem, a urządzenie z drugim interfejsem lub radiem komórkowym całkowicie opuszcza twoją ścieżkę egzekwowania. Jeśli to zdanie jest nie do przyjęcia dla danego urządzenia, odpowiedź już masz: użyj układu B.

Układ B: osobny port zamyka urządzenia wewnątrz

Tutaj Pi zachowuje 192.168.50.2 na łączu w górę z bramą 192.168.50.1 i bierze 10.20.0.1/24 na drugim interfejsie dla podłączonych urządzeń. Pi jest teraz routerem z dwiema sieciami, a podłączony segment ma dokładnie jedno wyjście.

Sprawdź zakres wobec wszystkiego innego, zanim się zobowiążesz: podsieci samego tunelu, innych prefiksów międzylokalizacyjnych i wszystkiego, co jest osiągalne przez VPN. 10.20.0.0/24, która koliduje z odległą siecią LAN, daje ten na wpół działający wynik, którego diagnoza zajmuje wieczór. Jeśli drugi port to adapter USB, potwierdź, że jest obsługiwany, i przypnij jego nazwę w menedżerze sieci, aby przestawienie po restarcie nie przesunęło twojego adresu LAN.

Uruchom nasłuch DHCP tylko na tym interfejsie. Serwer odpowiadający na łączu w górę konkuruje z routerem ISP i rozdaje adresy twojego segmentu reszcie domu. Zwiąż go z interfejsem LAN, ogranicz do zadeklarowanego zakresu i trzymaj własny adres Pi poza pulą.

Przekazywanie, tłumaczenie i reguła zamykania przy awarii

Cztery rzeczy bywają opisywane jako jedna i nią nie są. Włączenie przekazywania (net.ipv4.ip_forward=1) mówi jądru tylko, że może przenosić pakiety między interfejsami; samo w sobie niczego nie pozwala i nie gwarantuje żadnej ścieżki. Wybór wyjścia to decyzja routingu. Zezwolenie na pakiet to decyzja polityki w łańcuchu forward. Przepisanie jego źródła to decyzja postrouting. Budowa, która robi tylko pierwsze, daje Pi, który ochoczo przekazuje ruch klientów na zewnątrz przez łącze w górę.

Ogranicz zezwolenie do źródeł, które miałeś na myśli, i do interfejsu, którego ruch ma używać, i uwzględnij drogę powrotną oraz własne potrzebne cele Pi. Potem tłumacz na wyjściu tunelu, jeśli dostawca nie routuje twojego prefiksu LAN z powrotem do ciebie. podręcznik nftables traktuje przekazywanie, wyjście lokalne i tłumaczenie źródła jako osobne operacje, co jest tu właściwym modelem myślowym.

Częstą usterką jest szeroka reguła masquerade na interfejsie fizycznym. Wtedy ruch dociera do internetu drogą ISP, podczas gdy od strony klienta wygląda dokładnie jak działający VPN. To niczego nie dowodzi. Trzymaj tłumaczenie związane z zadeklarowanym wyjściem i trzymaj swoje reguły w zaporze, której host już używa, zamiast dodawać konkurencyjny zestaw reguł, który opróżnia współdzielony łańcuch postrouting.

Potem zajmij się brakiem tunelu. Profil klienta, który instaluje szeroką trasę domyślną, oznacza też, że gdy tunel padnie, zwykła trasa domyślna może wrócić i ruch klienta po cichu wraca na łącze w górę. Tam, gdzie powrót do jawnego tekstu jest nie do przyjęcia, polityka forward musi wyraźnie odmówić ruchu od klienta do łącza w górę, w stanie, w którym trasy VPN nie ma. Napisz to jako regułę odrzucania, a nie jako założenie. Własny zaszyfrowany transport Pi do partnera VPN to osobny strumień local-output i musi pozostać dozwolony, inaczej tunel nigdy nie wróci.

DNS i IPv6 potrzebują własnej odpowiedzi

Jeśli klienty używają Pi jako resolvera, trafiają na lokalnego nasłuchiwacza i Pi rozpoczyna nowe zapytanie. To zapytanie w górę podąża własną trasą Pi, a nie regułą forward, którą napisałeś dla klientów, więc ścieżka klienta tylko przez tunel plus resolver wychodzący bezpośrednio to wyciek bez żadnego komunikatu o błędzie. Zdecyduj świadomie: resolver osiągany przez tunel albo lokalny, który akceptujesz jako bezpośredni, i dopasuj własną politykę wyjścia Pi do tej decyzji.

IPv6 to znów osobny przypadek. Reguła forward dla IPv4 niczego nie ogranicza w kwestii IPv6, a ogłoszenia routera na łączu w górę mogą dać Pi, a przez niego podłączonemu segmentowi, drugą trasę domyślną, która omija twoją politykę. Albo daj IPv6 własną chronioną ścieżkę na tej samej zasadzie, albo ogranicz je wyraźnie w segmencie klientów i powiedz to.

Przetestuj granicę, zanim jej zaufasz

Przyjmij projekt dopiero po czterech osobnych sprawdzeniach, bo kuszący pojedynczy test — otwarcie przeglądarki na jednym kliencie — przechodzi w kilku zepsutych stanach.

Potwierdź, że jeden prawdziwy klient dociera do internetu przez tunel, a potem potwierdź, że ten sam klient nie dociera do internetu przy opuszczonym tunelu. Potwierdź, że rozwiązywanie DNS działa i że zapytanie wychodzi tam, gdzie zamierzałeś. Potwierdź, że własny transport Pi nadal działa po restarcie tunelu i że odzyskanie nie wymaga restartu maszyny. Na koniec sprawdź urządzenie, którego nie wybrałeś: w układzie A powinno nadal działać normalnie, a w układzie B nie powinno w ogóle istnieć w tym segmencie.

• Dwa porty i reguła odrzucania dają egzekwowanie; jeden port i opcja DHCP dają radę.
• Tłumaczenie na niewłaściwym interfejsie wygląda jak sukces i nim nie jest.
• Własny ruch Pi, DNS i IPv6 każdy potrzebuje decyzji, a nie wniosku.