Jeden publiczny host dla VPN i sieci: jak podzielić role

Jedna maszyna może zaspokoić wszystkie trzy potrzeby naraz: kończyć tunele, odpowiadać po HTTPS i przekazywać ruch między dwiema prywatnymi sieciami LAN. Czy to rozsądne, sprowadza się do trzech rzeczy, które można ustalić na papierze: kto jest właścicielem publicznego adresu, kto jest właścicielem każdej pary portu i protokołu oraz który proces może przekazywać pakiety. Jeśli te rzeczy są poprawne, współdzielony host nie jest niczym szczególnym. Jeśli są błędne, spędzisz weekend z usługą, która uruchamia się czysto i nigdy nie odpowiada.

To, co następuje, jest procedurą decyzyjną, a nie arkuszem budowy. Każdy krok kończy się sprawdzeniem, które dowodzi, że dodana przed chwilą rola jest rzeczywiście odizolowana.

Wybierz właściciela adresu przed portami

Punkt końcowy tunelu i serwer WWW mogą współdzielić jądro; współdzielenie jednego adresu, portu i protokołu w tym samym czasie jest tym, co zawodzi. WireGuard zwykle zajmuje UDP 51820, OpenVPN zajmuje UDP 1194 lub TCP 443, a serwer WWW zajmuje TCP 443. Bolesna para to OpenVPN po TCP 443 obok HTTPS, bo oba chcą tego samego gniazda, a jądro daje je temu, kto związał się pierwszy. Tylko demultiplekser z przodu, taki jak sslh lub proxy świadomy TLS, pozwala im dzielić ten port, i dodaje komponent, którego awaria wygląda dokładnie jak problem z zaporą ogniową.

Spójrz na właścicieli, zanim cokolwiek zmienisz: ss -lntup wypisuje lokalny adres, port i proces każdego nasłuchującego gniazda. Dwa wiersze pokazujące 0.0.0.0:443 oznaczają, że druga usługa nigdy się nie związała, choćby jej skrypt init był bardzo wesoły. Mostkowanie także przenosi właściciela. Gdy eth0 dołącza do br0, adres IP przechodzi na br0 i każda reguła zapory, która wymienia eth0, przestaje pasować, więc zwiąż usługi na moście i potwierdź za pomocą ip -br addr.

Ta sama zasada własności wyjaśnia niespodziankę, która pojawia się z maszynami wirtualnymi. Serwer tunelu działający wewnątrz gościa w tej samej sieci LAN zachowuje adres gościa, więc połączenia kierowane na adres samego hosta zostają na hoście, a tunel gościa nigdy ich nie widzi, cokolwiek twierdzi profil klienta.

Rutuj między dwiema sieciami LAN albo zrób NAT po jednej stronie

Dwie sieci LAN, które się nie widzą, mogą każda wybrać publiczny host, który następnie przekazuje ruch między tunelami. Ten rutingowy projekt wymaga trzech rzeczy: włączonego przekazywania, trasy do każdego zdalnego prefiksu i polityki przekazywania, która przepuszcza tranzyt. sysctl -w net.ipv4.ip_forward=1 obejmuje pierwszą, ip route add 10.20.0.0/24 dev wg1 drugą, a linia nftables taka jak nft add rule inet filter forward iifname "wg0" oifname "wg1" accept trzecią.

NAT źródłowy jest łatwiejszy do dodania i trudniejszy do debugowania. Maskowanie przepisuje adres klienta, więc dalsza strona widzi koncentrator, a nie prawdziwy host, a jej reguły dostępu i logi przestają być użyteczne do atrybucji. Gdy obie sieci są twoje, rutuj. Gdy jedna strona należy do osoby trzeciej, która nie doda trasy powrotnej, NAT jest opcją, która wychodzi w tym tygodniu. Tak czy inaczej, zapisz plan adresacji, bo dwóch nakładających się /24 nie da się rutować żadną konfiguracją.

Nic w tym, że komputer służy jako wyjście do internetu dla laptopa, nie przeszkadza temu samemu komputerowi kończyć tunele przychodzące. Przeszkadzają tylko nakładające się adresy, i dlatego plan adresacji jest dokumentem, który ma znaczenie.

Przetestuj podział, gdy dwie role są zatrzymane

Użyteczny test to odejmowanie: zatrzymaj dwie role i potwierdź, że trzecia nadal odpowiada. Żądanie WWW powinno się zakończyć przy wyłączonej usłudze tunelu, a uzgadnianie tunelu powinno się zakończyć przy zatrzymanym serwerze WWW. Jeśli oba działają tylko wtedy, gdy wszystko działa, masz przypadkową zależność, na przykład wspólną tabelę zapory, zabłąkaną trasę lub nazwę wskazującą zły adres.

Trzy polecenia czynią ten test konkretnym. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ dowodzi, że lokalny nasłuch odpowiada bez zewnętrznego DNS, wg show na kliencie dowodzi, że uzgadnianie się zakończyło, a tcpdump -ni any port 51820 na koncentratorze oddziela problem rutowania od problemu z kluczem. Uzgadnianie, które nigdy nie pojawia się w przechwyceniu, zginęło przed hostem: zapora dostawcy, zły publiczny adres lub reguła NAT po drodze.

Powtórz odejmowanie dla sieci LAN, które są przekazywane. Przy jednym peera odłączonym ping przez koncentrator powinien zawieść; po ponownym połączeniu ping powinien wrócić bez dotykania reguły. Ping, który wraca dopiero po restarcie tunelu, wskazuje na politykę, a nie na osiągalność, i to inna poprawka.

Utrzymuj zbiór reguł czytelnym, gdy odejmujesz role. nft list ruleset powinien pokazywać jedną regułę akceptacji na każdy kierunek, którego naprawdę potrzebujesz, a łańcuch przekazywania, który akceptuje wszystko, nie jest rozdzieleniem, to działające demo.

Linie dostępu tylko IPv6 i usługi IPv4

Niektóre linie dostępu dają tylko osiągalność IPv6, a usługi nadal trzeba publikować przez IPv4. Sam tunel jedzie przez rodzinę, która jeszcze przepuszcza ruch, podczas gdy opublikowana usługa siedzi na adresie wewnątrz tunelu. To odwraca zwykłe założenie i po cichu psuje monitorowanie: reguła zapory lub sprawdzenie dostępności napisane dla ścieżki IPv4 pilnuje teraz interfejsu, który nic nie przenosi.

Testuj każdą rodzinę osobno za pomocą curl -4 i curl -6, bo jedno udane żądanie nic nie mówi o ścieżce, której nie wypróbowałeś. Własność portów nie zmienia się między rodzinami, ale nasłuch już tak: ss -lntup wymienia gniazda IPv4 i IPv6 w osobnych wierszach, a 0.0.0.0:443 nie obejmuje [::]:443, chyba że proces poprosił o gniazdo dual-stack.

Usługa, która odpowiada w jednej rodzinie, a odmawia w drugiej, to zwykle problem nasłuchu, nie rutowania. Zanim uznasz projekt za gotowy, potwierdź, że każda rola ma własny adres lub port, że przekazywanie jest włączone i dozwolone, oraz że każda rola nadal odpowiada, gdy pozostałe dwie są zatrzymane.