LAN směrovač a VPN klient: dvě zařízení, dvě směrovací tabulky

Dvě zařízení předávají paket dál a každé si drží vlastní tabulku. LAN směrovač ví, že vzdálený prefix patří VPN klientovi, a VPN klient ví, jak se k tomu prefixu dostat svým tunelem. Nakonfigurujte jen první tabulku a paket dorazí ke stroji, který nemá odpovídající trasu, takže zase odejde přes výchozí bránu. To je celá závada a z pohledu LAN to vypadá jako směrovací smyčka, protože skoro je.

Nakreslete oba skoky, než se dotknete trasy

Vezměte ilustrativní uspořádání: hostitelé LAN na 192.168.50.0/24, běžný směrovač na 192.168.50.1, vyhrazený klient na 192.168.50.15 a vzdálená LAN na 10.60.0.0/24 dostupná jen tunelem, který tento klient drží. Ani jedno privátní rozmezí se s druhým nepřekrývá, a tunel má vlastní plán adres.

Obě privátní rozmezí jsou důležitá, protože určují, které zařízení může odpovědět. Vzdálená strana uvidí paket přicházet z tunelové adresy klienta a její odpověď si musí najít cestu zpět na 192.168.50.0/24. Pokud je nakonfigurován jen odchozí směr, požadavek může fungovat, zatímco odpověď zmizí.

Krok 1: nasměrujte směrovač na klienta, ne na tunel

Na LAN směrovači přidejte cílovou trasu, jejíž další skok je LAN adresa klienta:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Tento záznam říká „doruč to stroji, který umí tunelovat“. Neříká nic o tom, jak je tunel postaven, a nenahrazuje klientovu vlastní trasu. Na spravovaném směrovači žije ekvivalent na stránce statických tras zařízení; na Linux směrovači patří do konfigurace rozhraní, které vlastní LAN, ne do shellu, který zavřete.

Zkontrolujte odpověď druhého příkazu. Pokud hlásí klienta jako gateway a LAN rozhraní jako device, první skok je správný a zbývající práce je na druhém stroji.

Krok 2: dejte klientovi vlastní trasu na straně tunelu

Klient teď dostane paket pro 10.60.0.0/24 a podívá se do své tabulky. Pokud jeho tunelová konfigurace nainstalovala trasu pro tento prefix, paket pokračuje šifrovaně. Pokud ne, paket odpovídá běžné výchozí trase a vrátí se na 192.168.50.1, který ho pošle znovu klientovi.

Podívejte se, než něco přidáte:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

Chybějící trasa prefixu ve všech tabulkách je nález, který hledáte. Přidejte ji přes vlastní konfiguraci tunelu, aby ji příští opětovné připojení znovu nainstalovalo; ruční ip route add zmizí se sezením a závada se vrátí v nejméně vhodnou chvíli. Dalším skokem je tunelové rozhraní nebo adresa, kterou VPN přiděluje jako svého protějšku, podle klienta, a adresa protějšku by měla pocházet z aktuálního profilu, ne ze staré poznámky.

Smyčka, když nastane, není v praxi nekonečná: TTL při každém průchodu klesá a paket umírá se zprávou o překročení času. Proto opakovaný traceroute může naznačovat cyklus, zatímco klient, který prostě nepředává, tentýž paket tiše zahodí.

Krok 3: povolte předávání a vyberte zpětnou cestu

Přijímat a předávat jsou různá oprávnění. net.ipv4.ip_forward=1 na klientovi povoluje tranzit na úrovni jádra a pravidlo firewallu ho ještě musí povolit mezi LAN rozhraním a tunelem. Pravidlo, které povoluje přístup ke stránce správy klienta, nepovolí tranzit do vzdálené LAN, a tento rozdíl snadno přehlédnete, když stejný hostitel lokálně odpovídá na pingy.

Vzdálená strana má zrcadlový problém. Musí vědět, že 192.168.50.0/24 je dostupná přes tohoto ověřeného klienta. S OpenVPN to obvykle znamená trasu pro jednotlivé klienty, kterou protlačí konfigurace serveru, nebo soubor specifický pro klienta na serveru, který deklaruje LAN za klientem. Bez toho vzdálená LAN buď odpověď zahodí, nebo ji pošle na svou výchozí bránu, což je internet.

Překlad zdroje je alternativa, když prefix LAN nelze inzerovat. Omezené pravidlo masquerade na klientovi přepíše zdroj na tunelovou adresu a odpovědi se pak vracejí přirozeně. Také skrývá, který hostitel LAN požadavek odeslal, a samo o sobě neumožňuje vzdálené straně iniciovat spojení dovnitř. Zvolte tento kompromis vědomě, místo abyste přidali plošné masquerade a vedlejší účinek objevili později.

Krok 4: obě rozhodnutí zajistěte trvale, pak otestujte skutečnou cestu

Každá trasa má vlastníka a vlastníkem je konfigurace, která se obnovuje při startu nebo při opětovném připojení. Na směrovači to může být záznam statické trasy; na klientovi to může být profil VPN, NetworkManager nebo systemd-networkd. Ověřte opětovným připojením tunelu a restartem klienta, pak tabulku přečtěte znovu, místo abyste věřili úpravě.

Výchozí trasu, která nese vnější spojení tunelu, nechte nedotčenou. Nahrazení kvůli „zjednodušení“ nastavení rozbije šifrovanou cestu dřív, než ji jakýkoli vnitřní provoz stihne použít, a příznakem je tunel, který se po změně už nikdy nenaváže.

Testujte z běžného hostitele LAN, ne z klienta, protože požadavek vzniklý na klientovi nikdy neprocvičí první skok směrovače. Stáhněte službu, která existuje jen ve vzdálené LAN, a potvrďte tělo odpovědi, pak zkontrolujte čítače nebo logy klienta, abyste viděli tranzit. Vnitřní traceroute se soukromými skoky dokazuje předávání, ne šifrování: vnější cesta je samostatné pozorování a jen čítače rozhraní tunelu ukazují, co přes něj odešlo.