Veřejný prefix přes OpenVPN: oprava zpáteční cesty

Sledujte, jak tunel naskočí a klient pinguje druhou stranu, a pak veřejná adresa, která patří za VPN, odpovídá odjinud, nebo vůbec. Tento příznak obvykle nemá nic společného se šifrou ani s certifikáty. Prefix směrovaný poskytovatelem se dodává jako IP trasa, a přenést ho přes OpenVPN znamená reprodukovat tuto trasu na dvou úrovních a zachovat zdrojovou adresu na zpáteční cestě. Přemosťovat WAN není nutné a přidání adresy na rozhraní nevytvoří nadřazenou trasu.

Prefix musí být nejdřív směrován k vám

Zeptejte se poskytovatele, jak se blok dodává. Prefix směrovaný na hlavní adresu vašeho serveru je jiná věc než adresy, které poskytovatel očekává přímo na WAN segmentu. S tímto návrhem funguje jen první model.

Pokud poskytovatel směruje 198.51.100.64/28 na váš vstupní server, pakety pro tento rozsah dorazí na server a tam se zastaví, pokud je nepřeposíláte. Pokud poskytovatel rozsah místo toho přemostí na váš uplink, musí server na ARP pro něj odpovídat, což je jiný problém.

Otestujte model dodání, než se dotknete OpenVPN: zvenčí pingněte adresu v bloku a sledujte, které rozhraní ji přijme. Pokud nic nedorazí, žádná konfigurace tunelu nepomůže. Pokud adresa odpovídá přímo na WAN, poskytovatel přemostí místo směrování a návrh níže neplatí.

Dvě úrovně směrování: trasa v jádru a iroute

OpenVPN potřebuje prefix na dvou místech. Jádro musí vědět, že prefix patří tunelovému zařízení, aby přeposílané pakety vstoupily do OpenVPN místo výchozí trasy. OpenVPN také musí vědět, který autentizovaný klient prefix vlastní, což je záznam iroute v adresáři specifickém pro klienta.

Trasa na straně serveru vypadá takto, přičemž prefix a maska musí odpovídat přidělení:

ip route add 198.51.100.64/28 dev tun0

Konfigurace specifická pro klienta přiřazuje vlastnictví. Vložte ji do souboru CCD pojmenovaného podle běžného názvu klientského certifikátu a ověřte, že právě tento adresář server skutečně čte:

iroute 198.51.100.64 255.255.255.240

Dokumentace OpenVPN ke směrovaným sítím popisuje obě úrovně a proč jsou oddělené. Trasa v jádru bez iroute posílá pakety do tunelu bez vlastníka a OpenVPN je zahazuje. iroute bez trasy v jádru nechává pakety na výchozí cestě serveru. Obě chyby vypadají z klientské strany jako rozbitý tunel.

Kde žije adresa služby

Delegovaný prefix není totéž jako vlastní adresy tunelu. Link očíslujte z privátního prostoru, pokud chcete, a umístěte veřejnou adresu služby tam, kde služba skutečně běží.

Na klientu Linux, který službu ukončuje lokálně, stačí jedna adresa hostitele:

ip address add 198.51.100.70/32 dev lo

Pokud se prefix směruje dál na hostitele VM nebo jinou LAN, nakonfigurujte místo toho tuto cestu po proudu a její zpáteční trasu. Přiřazovat každou adresu v bloku VPN klientovi není nutné a později vytváří konflikty.

Zachovejte veřejný zdroj na zpáteční cestě

Odpověď z delegovaného prefixu musí vyjít tunelem a dosáhnout trasy poskytovatele. Pokud ji vzdálený hostitel pošle přes svého ISP, zdrojová adresa vypadá podvrženě a poskytovatel nebo cíl ji zahodí. Řešením je pravidlo založené na zdroji nebo vyhrazená směrovací tabulka, ne širší NAT. Bez něj služba funguje od protějšku tunelu a selhává odjinud.

Na vstupním serveru je široké pravidlo masquerade obvyklý viník. Přepisuje veřejný zdroj na hlavní adresu serveru a klient skutečný nikdy nevidí:

iptables -t nat -S POSTROUTING

Omezte NAT na privátní VPN klienty, kteří ho potřebují, a delegovaný prefix nechte nepřeložený. Pak ověřte, že server prefix vůbec přeposílá, protože přeposílací řetězec se zakázáním podle výchozího nastavení ho tiše zahazuje.

Ověřte oba směry, než tomu budete věřit

Ověření jsou čtyři pozorování, ne jedno. Ověřte, že trasa poskytovatele dorazí, jádro pošle prefix do tunelu, OpenVPN ho přiřadí správnému klientovi a odpověď se vrátí s neporušeným veřejným zdrojem. Každé pozorování má svůj příkaz, takže selhání ukazuje na vrstvu, ne na celý návrh. Spouštějte je v tomto pořadí po každé změně konfigurace.

Zeptejte se jádra, kterou cestou se delegovaná adresa vydá, a sledujte tunel, dokud běží požadavek:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Filtrování zpětné cesty může zrušit správnou trasu. Zkontrolujte efektivní nastavení na tunelu a na uplinku a pamatujte, že striktní režim odmítá provoz, jehož zdroj neodpovídá rozhraní, na které dorazil:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

Nakonec otestujte případ selhání. Zastavte tunel a ověřte, že veřejný prefix neuniká běžným uplinkem. Obnovení VPN má vrátit službu, aniž by rozšířilo porty, které hostitel otevírá.