Proszę o pomoc w routingu, w oparciu o zasady?

Mój domowy router to niestandardowe urządzenie Arch Linux. Dla pewnej dodatkowej prywatności / bezpieczeństwa mam go skonfigurowanego jako klienta OpenVPN dla serwera OpenVPN, działającego na VPS, którego używam. Cały mój domowy ruch przechodzi przez ten tunel VPN 24/7. Ta konfiguracja działa idealnie.

Czasami chciałbym, aby pewien ruch omijał tunel VPN i korzystał z mojego regularnego połączenia bez VPN. Docelowe adresy IP są liczne i zróżnicowane, więc nie jest możliwe po prostu statyczne trasy statyczne.

Zamiast tego pomyślałem, że skonfiguruję instancję serwera openvpn na routerze, dostępną dla klientów w sieci LAN, a następnie użyję routingu opartego na zasadach, aby skierować cały ruch z tej podsieci VPN (połączonych klientów) bezpośrednio przez moje połączenie internetowe, omijając tunel, przez który przechodzi cały inny ruch internetowy. W ten sposób klienci w mojej sieci domowej mogą połączyć się z tym wewnętrznym VPN i połączyć się z Internetem bez przechodzenia przez tunel VPN routera.

Czy to brzmi jak możliwe? Czy mam rację, sądząc, że mógłbym użyć routingu opartego na źródle za pośrednictwem oddzielnej tabeli routingu, aby ominąć tunel VPN klienta routera? Jakieś pułapki lub szczegóły (związane z iptables lub tablicami routingu), o których powinieneś wiedzieć, aby to zadziałało?

Z góry dziękuję.

Jeśli dobrze rozumiem, normalnym działaniem hosta w sieci jest po prostu korzystanie z Internetu z jego DHCP lub podobnie dostarczoną konfiguracją LAN, a jego domyślna trasa jest dostępna za pośrednictwem usługi VPN, powiedzmy interfejs tun0

Czasami jednak nie chcesz używać domyślnej tun0trasy do aktywności sieciowej na co najmniej jednym hoście. Zamiast wyłączać usługę VPN dla całej sieci, proponujesz zamiast tego utworzyć tunel VPN z hosta LAN do serwera linux, powiedzmy tun1, z własną podsiecią, powiedzmy subnetB, inną niż zwykła sieć hosta LAN, powiedzmy subnetA. Chcesz, aby ruch subnetAbył domyślnie przekierowywany tun0, ale ruch z lokalnych sieci VPN, subnetBaby nie wychodził przez tunel, ale wychodził przez niego bez eth0tunelu.

Sugeruję, zamiast tworzyć opartą na źródłach trasę polityki opartą na subnetAlub subnetB, że do przypisania polityki używasz interfejsu przychodzącego: Ruch przychodzący na eth1liściach włączony tun0. Ruch przychodzący na tun1liściach włączony eth0.

Aby kontynuować, udało mi się zrealizować mój pierwotny plan.

Skonfigurowałem serwer openvpn na routerze, dostępny tylko z domowej sieci LAN. Jeśli klient w mojej domowej sieci LAN chce uzyskać dostęp do Internetu i ominąć połączenie VPN, które router zwykle kieruje cały ruch wewnętrzny do Internetu, łączy się z wewnętrzną siecią VPN. Ten serwer VPN jest skonfigurowany do przekazywania statycznych adresów IP na podstawie certyfikatu klienta. Następnie skrypt cl-connect.sh tworzy osobną tabelę routingu i reguły routingu, dzięki czemu określone, z góry określone adresy IP przypisane klientom w wewnętrznej sieci VPN są kierowane przez alternatywną tabelę routingu, która informuje wszystkie te połączenia, aby zakończyły połączenie do Internetu nie używając interfejsu tun0 dla całego routera, ale interfejs ethv unvpn-d, który łączy się bezpośrednio z moim dostawcą usług internetowych. Kiedy klienci LAN rozłączają się, skrypt cl-disconnect.sh usuwa również trasy.

W ten sposób cały mój domowy ruch LAN nadal jest domyślnie przesyłany do szerokiego Internetu przez router i jego interfejs tun0 do VPN dla całego routera. Ale klienci łączący się z tym nowym wewnętrznym serwerem VPN kierują swój ruch do Internetu, omijając router VPN i adres IP przypisany przez mojego dostawcę usług internetowych.

Chyba zastanawiam się, czy użycie OpenVPN w jakiś sposób nie jest przesadne, a prosta konfiguracja serwera proxy (Squid?) Może być mniej obciążająca dla routera. Niemniej jednak to działa. Dzięki wszystkim, którzy się włączyli.