Pi VPN z wieloma routerami: umieść każdą trasę na urządzeniu, które decyduje

Router poniżej dodaje drugą podsieć klienta, a każde z czterech urządzeń ma jedną decyzję. Umieść trasy, sprawdź źródło, a potem przetestuj z prawdziwego klienta.

Umieszczenie skrzynki Wi-Fi za Pi zamienia jedną decyzję routingu w cztery, a plan się rozsypuje, gdy wszystkie cztery zapadają na jednym urządzeniu. Pierwsze pytanie nie brzmi, którą trasę dodać. Lecz czy nowa skrzynka mostkuje, czy routuje, bo ta odpowiedź decyduje, ile jest podsieci i które urządzenia muszą się o nich dowiedzieć. Najpierw wybierz model podłączenia; każda trasa z niego wynika.

Most czy routing: wybór, który ustala liczbę

Most stawia nowych klientów w tej samej podsieci, którą Pi już obsługuje. Jedna podsieć, jedna władza DHCP i żadne przekazanie do routingu. To prostszy układ i właściwy, gdy osobna sieć klientów nigdy nie była wymaganiem. Łącze routowane to inny projekt: skrzynka zachowuje własną podsieć, a ten prefiks musi być przenoszony wszędzie, gdzie idzie ruch.

Reszta planu zachowuje router poniżej i chroni adresy źródłowe klientów. Celem jest jedna prywatna sieć VPN, a nie pełne wyjście do internetu. Zapisz model przed adresami, bo lista poniżej to tylko przykład połączenia routowanego.

client subnet       10.41.0.0/24
client gateway      10.41.0.1
router-to-Pi link   192.168.71.2
Pi on that link     192.168.71.1
private target      10.72.9.0/24

Kto co decyduje

Decision ownerEntry that encodes the decisionFailure when the entry is missing
Pi VPN hostReturn route for 10.41.0.0/24 via 192.168.71.2, and a tunnel route for 10.72.9.0/24Replies to downstream clients die at the Pi
Owner of the remote networkA path for 10.41.0.0/24 over the permitted tunnelReplies stop at the first unaware hop
LAN router behind the PiSpecific route for 10.72.9.0/24 via 192.168.71.1, or a suitable defaultClients never send private traffic to the Pi
Client machineDefault via 10.41.0.1, or a specific entry for 10.72.9.0/24The private network is unreachable from the client

Każde urządzenie podejmuje jedną decyzję i żadne nie może podjąć decyzji innego za nie. Pi potrzebuje dwóch wpisów, a nie jednego, a droga powrotna jest tą, o której ludzie zapominają. Przekazywany ruch dociera poprawnie do prywatnej sieci, a potem ginie w drodze powrotnej, bo Pi nie ma pojęcia, gdzie mieszka 10.41.0.0/24. To wygląda na problem zapory i naprawdę jest brakującą trasą.

Druga strona też potrzebuje własnej trasy. Jeśli usługa na dalekim końcu nie wie, że 10.41.0.0/24 jest osiągalny przez twój tunel, odpowiedzi zatrzymują się na pierwszym skoku bez odpowiedzi. Dodaj oba kierunki, zanim zaczniesz czytać filtry pakietów.

Następne skoki pochodzą z podłączenia

Następny skok musi być adresem w sieci, do której urządzenie naprawdę może dotrzeć. Publiczny adres peera VPN nie jest następnym skokiem dla prywatnej podsieci, a odległa sieć usług nie jest żadnym następnym skokiem. Trasa do nieosiągalnej bramy wygląda poprawnie na liście i odrzuca każdy pakiet. Sprawdź, czy brama odpowiada, zanim obwinisz cel.

Utrzymuj zewnętrznego peera VPN Pi osiągalnym przez jego własną trasę podkładową. Ten wpis jest oddzielny od tras ładunku, a ich mieszanie daje tunel, którego nie da się odtworzyć po zmianie ścieżki.

Dokumentacja tras statycznych jasno pokazuje różnicę między celem a bramą, choć każda platforma nazywa swoje menu inaczej. Czytaj dokumentację urządzenia przed sobą, zamiast kopiować ekran innego producenta. Polecenia poniżej pokazują kształt wpisów w Linuksie.

# on the Pi
ip route add 10.41.0.0/24 via 192.168.71.2
ip route add 10.72.9.0/24 dev tun0
# on the downstream router
ip route add 10.72.9.0/24 via 192.168.71.1

Co tłumaczenie robi ze źródłem

Jeśli router poniżej już tłumaczy swoich klientów na adres tranzytowy, Pi widzi jedno przetłumaczone źródło zamiast adresu każdego klienta. To inny projekt niż zachowujący źródło powyżej. Zmienia politykę opartą na źródle, rejestrowanie i to, która strona może inicjować połączenia. Oba projekty działają; odpowiadają na różne pytania.

Gdy usługa VPN powyżej odmawia routowania prefiksu klienta z powrotem, wąskie tłumaczenie na wyjściu tunelu Pi może być uzasadnionym obejściem. To nie dowód, że brakująca trasa była zbędna. Zapisz, jaki adres odległa sieć naprawdę widzi i jaka droga powrotna z tego wynika.

Wybór trasy, zgoda na przekazywanie i tłumaczenie źródła pozostają trzema osobnymi zadaniami. Wyczyszczenie współdzielonego łańcucha NAT lub zezwolenie każdemu interfejsowi, bo jeden klient przewodowy działa, to sposób, w jaki działający test staje się otwartym przekazywaczem.

Udowodnij to z maszyny klienta

Wyślij żądanie z maszyny w dolnej sieci LAN, a następnie śledź jego źródło na zewnątrz i z powrotem. Ping wysłany przez Pi nigdy nie ćwiczy dolnej trasy powrotnej, dlatego udany ping dowodzi mniej, niż się wydaje. Dodaj drugi test z klienta przewodowego we własnej sieci LAN Pi, aby można było porównać obie ścieżki. Powtórz oba po restarcie dowolnego urządzenia.

Trasy dodane ręcznie i tłumaczenia, które nigdy nie zostały zapisane, znikają razem. Wtedy para wygląda jak nowa usterka, a nie niedokończona praca.

Zapisz model podłączenia razem z trasami, dozwoloną usługą prywatną i każdym tłumaczeniem w jednej notatce. To ta notatka powstrzymuje następną osobę przed traktowaniem umiejscowienia bezprzewodowego jako kwestii polityki routingu.

Powiązane artykuły