Proč je podsíť za klientem OpenVPN nedostupná?

Pingy na tunelovou adresu serveru procházejí, vlastní směrovací tabulka klienta vypadá správně a LAN za tímto klientem je stále nedostupná. Směrovací tabulka klienta vypadá korektně, server má trasu směřující do tunelu a pakety stále mizí. To je klasický příznak tunelu layer-3, který netuší, že jeden z jeho klientů je zároveň brána.

Rozhraní tun nemá další skok pro jednotlivé klienty. Jádro vidí jedno rozhraní s mnoha protějšky, takže rozhodnutí, který klient má dostat paket pro vzdálenou LAN, se musí udělat uvnitř procesu OpenVPN. Toto rozhodnutí se konfiguruje pomocí iroute a bez něj paket nemá kam jít.

Server směruje podle klienta, ne podle rozhraní

Když server potřebuje poslat paket na tunelovou adresu klienta, odpověď je jednoznačná: adresa patří relaci tohoto klienta. Když je cílem celá podsíť za tímto klientem, adresa nepatří nikomu, koho server zná, a trasa jádra do tunelu říká jen "tímto rozhraním", aniž by určila protějšek.

OpenVPN to řeší vnitřní směrovací tabulkou, která přiřazuje cílový prefix konkrétnímu klientovi. Tato tabulka se sestavuje ze záznamů iroute, proto běžná trasa na hostiteli serveru nestačí. Trasa jádra dostane paket k tunelovému rozhraní; vnitřní mapování rozhodne, která relace jej přijme. Proto se oprava nikdy neobjeví ve výstupu tras jádra.

Pokud mapování chybí, paket dorazí na server, odpovídá tunelové trase a je zahozen, protože žádný klient si cíl nenárokuje. Nic nezapíše čistou chybu, proto porucha vypadá jako tichá černá díra, ne jako směrovací smyčka.

Zapsání záznamu iroute, který pojmenuje klienta

iroute žije v konfiguračním souboru konkrétního klienta, ne v hlavní konfiguraci serveru. Nasměrujte server na adresář volbou client-config-dir, poté vytvořte soubor, jehož název je běžný název certifikátu klienta, a vložte do něj prefix.

Pro pobočku, jejíž LAN je 10.20.0.0/24 a jejíž běžný název certifikátu je branch-router, obsahuje soubor na této cestě řádek jako iroute 10.20.0.0 255.255.255.0. Hlavní konfigurace potřebuje jen volbu adresáře; prefix žije u klienta.

Běžný název je křehká část. Certifikát vydaný s jiným subjektem, nebo nasazení, které ověřuje uživatele podle uživatelského jména, zatímco soubor je pojmenován podle certifikátu, vytvoří soubor, který se nikdy nepřečte. Zkontrolujte název, který server skutečně hlásí pro relaci, a zvažte volbu, která neodpovídajícímu klientovi dovolí selhat, místo aby se tiše připojil bez svých tras. Přejmenování souboru podle certifikátu je pětiminutová oprava, která zabrání velmi dlouhému večeru.

Jeden klient může vlastnit několik prefixů. Přidejte jeden řádek iroute pro každou síť a udržujte seznam vedle ostatního nastavení tohoto klienta, aby mapování zůstalo auditovatelné.

Budování zpětné cesty v obou směrech

Dostat pakety do vzdálené LAN je polovina práce. Klient musí také posílat provoz této LAN do tunelu, což se obvykle dělá pushnutím trasy klientovi: řádek jako push "route 10.8.0.0 255.255.255.0" říká každému klientovi, jak dosáhnout sítě na straně serveru. Pro pobočku ekvivalentní trasa ukazuje do tunelu pro vše, čeho má na straně serveru dosáhnout.

Zpětný směr potřebuje vlastníka na vzdálené straně. Tam musí někdo znát cestu zpět: statická trasa na routeru LAN, která směruje VPN pool na server, nebo překlad adres na serveru před vstupem provozu do LAN. Statická trasa udržuje původní adresy viditelné v protokolech a přístupových pravidlech, ale vyžaduje spolupráci vlastníka LAN; překlad je samostatný, ale skrývá, kdo se skutečně připojil.

Forwarding musí být na hostiteli serveru povolen. Bez něj jádro přijme paket z tunelu a odmítne jej předat do rozhraní LAN, což z pohledu klienta vypadá stejně jako chybějící iroute.

Ověření dostupnosti správnými sondami

Testujte po vrstvách, místo abyste pingovali vzdálený konec a hádali. Ze serveru ověřte, že vnitřní mapování pro prefix existuje a že trasa jádra ukazuje do tunelu. Z klienta potvrďte, že je pushnutá trasa nainstalována a že jeho výchozí cesta pro adresu LAN je tunel.

Pak sledujte pakety. Zachycení na tunelovém rozhraní ukáže, zda server vysílá směrem ke klientovi, a zachycení na rozhraní LAN ukáže, zda je předává dál. Pokud první ukazuje pakety a druhé nic, problém je ve forwardingu nebo ve filtru; pokud ani jedno nic neukazuje, vyhledání selhalo dříve.

Dva servery spojené tunelem opakují stejné pravidlo na obou stranách: každý potřebuje iroute pro pool toho druhého a každý potřebuje trasu a forwarding, které činí cestu symetrickou. Směrování a politika jsou zde oddělené záležitosti. Směrování rozhoduje, kam paket může jít, zatímco pravidlo FORWARD rozhoduje, zda smí, takže klient se dvěma řádky iroute dosáhne na oba prefixy, pokud filtr neřekne jinak.