Czy można używać dwóch VPN-ów na tym samym serwerze domowym bez konfliktów tras?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Can You Use Two VPNs on the Same Home Server Without Route Conflicts? - Zima Store Online

Tak, dwa VPN-y mogą współdzielić jeden serwer domowy, jeśli ich adresy, trasy, domyślne ustawienia, reguły zapory i ścieżki powrotne są wyraźnie rozdzielone.

Problemy zaczynają się, gdy oba tunele używają tej samej prywatnej podsieci, instalują konkurencyjne trasy domyślne, używają zduplikowanych identyfikatorów interfejsów lub tabel, globalnie zmieniają DNS lub wysyłają odpowiedzi innym tunelem niż ten, który odebrał żądanie. Bezpieczny projekt najpierw przypisuje każdemu VPN-owi odrębne zadanie — na przykład zdalny dostęp i komercyjny egress — a następnie testuje najpierw jeden tunel, potem drugi, a na końcu oba razem, rejestrując aktywną trasę dla każdego obciążenia.

Określ zadanie każdego VPN przed uruchomieniem obu

Zapisz, które klienty, cele, protokoły i aplikacje należą do VPN A i VPN B. Typowe rozwiązania to jeden serwer WireGuard przychodzący do zdalnego dostępu do NAS oraz jeden wychodzący komercyjny VPN dla wybranych kontenerów.

Społeczność OpenVPN podkreśla, że można uruchomić wiele tuneli jednocześnie, ale każda instancja wymaga osobnego wirtualnego adaptera, portu oraz unikalnej, niepokrywającej się podsieci.

Jeśli oba tunele mają przenosić cały ruch serwera, zdecyduj, który jest podstawowy, a który zapasowy lub zagnieżdżony. Dwie niezależne polityki „wysyłaj wszystko” nie mogą jednocześnie kontrolować tych samych pakietów bez wyraźnego ustalenia kolejności.

Zachowaj unikalność podsieci tuneli i zdalnych LAN-ów

Porównaj pule adresów obu tuneli, każdą reklamowaną zdalną sieć LAN, sieć domową, sieci kontenerów oraz typowe sieci zdalnych klientów. Żaden cel nie powinien odnosić się do dwóch różnych miejsc w tym samym kontekście trasowania.

Instrukcja OpenVPN wyjaśnia, że nakładające się sieci prywatne powodują niejednoznaczność trasowania, ponieważ system nie wie, która lokalizacja odpowiada zduplikowanemu adresowi. Różne prefiksy eliminują niejednoznaczność nakładających się adresów zanim uwzględni się metryki tras.

Jeśli to możliwe, zmień numerację jednego tunelu lub LAN-u. Jeśli nakładanie jest nieuniknione, stosuj kontrolowaną translację NAT, oddzielne przestrzenie nazw sieci, VRF-y lub tabele polityk zamiast polegać na tym, który tunel uruchomi się jako ostatni.

Zapobiegaj zastępowaniu trasy domyślnej przez oba VPN-y

Sprawdź tabelę tras bez VPN, z VPN A, z VPN B oraz z oboma aktywnymi. Zapisz trasy domyślne, trasy domyślne dzielone, takie jak 0.0.0.0/1 i 128.0.0.0/1, metryki oraz trasy do obu serwerów VPN.

Zgłoszenie OpenVPN zauważa, że przekierowywanie domyślnej bramy przez wiele jednoczesnych VPN-ów nie jest użyteczne, chyba że administrator zdecyduje o konkurencyjnych trasach domyślnych.

Wyłącz automatyczną instalację trasy domyślnej na tunelu, który ma obsługiwać tylko wybrane podsieci. Zachowaj trasę do każdego punktu końcowego dostawcy VPN przez podstawową sieć WAN, aby uruchomienie drugiego tunelu nie wysłało jego połączenia sterującego przez pierwszy.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Używaj trasowania polityk dla ruchu źródłowego lub specyficznego dla aplikacji

Utwórz oddzielne tabele tras dla ruchu, który musi wychodzić przez każdy VPN, a następnie wybieraj je według podsieci źródłowej, adresu kontenera, znacznika zapory, użytkownika lub interfejsu. Główną tabelę pozostaw dla zwykłego ruchu serwera domowego.

Przykład na Unix i Linux dotyczący wielu połączeń VPN zaleca reguły, aby ruch z każdego interfejsu korzystał z własnej tabeli tras i wracał przez właściwy modem lub tunel.

Dodaj reguły w udokumentowanej kolejności i testuj wyszukiwanie tras dla reprezentatywnych par źródło-cel. Tabela polityk bez połączeń LAN i tras powrotnych może izolować wybraną aplikację od reszty sieci domowej.

Wyrównaj NAT, zaporę, DNS i ścieżki powrotne

Dla każdego VPN udokumentuj, który interfejs przekazuje ruch, które adresy źródłowe są maskowane, które podsieci przychodzące są dozwolone oraz jaki serwer DNS otrzymują klienci. Stosuj NAT tylko tam, gdzie zdalna strona nie ma trasy powrotnej.

Przypadek z Server Fault dotyczący trasowania klientów WireGuard przez połączenie OpenVPN wyjaśnia, że ruch może wymagać maskowania, ponieważ zdalny VPN zna tylko adres klienta OpenVPN, a nie zdalną podsieć klienta WireGuard.

Sprawdź, czy odpowiedzi wychodzą przez tunel, który odebrał lub zainicjował sesję. Asymetryczne odpowiedzi mogą sprawić, że VPN będzie wyglądał na połączony, podczas gdy ruch TCP, DNS lub SMB będzie cicho zawodził.

Przetestuj awarie i kolejność ponownego uruchamiania przed użyciem produkcyjnym

Uruchom VPN A, potem B; odwróć kolejność; restartuj każdą usługę niezależnie; i zrestartuj serwer. Zapisz trasy, reguły, DNS, stan zapory i czy istniejący zdalny dostęp do zarządzania przetrwał.

Przewodnik ZimaSpace dotyczący naprawy brakującej trasy VPN podaje sekwencję odzyskiwania, gdy jeden tunel przypadkowo przechwytuje ruch drugiego.

Konfiguracja jest bezpieczna tylko wtedy, gdy oba tunele łączą się ponownie w dowolnej obsługiwanej kolejności, każde obciążenie podąża zamierzoną ścieżką, DNS pozostaje przewidywalny, a wyłączenie jednego VPN nie odcina ruchu zarządzania. Zachowaj lokalną konsolę lub ścieżkę odzyskiwania bez VPN przed automatyzacją obu usług przy starcie systemu.