OpenVPN: místní adresa versus adresa tunelu – dva různé sockety

Klient odmítá nastartovat a stěžuje si, že nemůže navázat místní adresu, a zřejmá oprava vypadá tak, že ho nasměrujeme na adresu tunelu, kterou očekává. To nemůže fungovat a důvod stojí za pochopení: dokud tunel neexistuje, žádná vnitřní adresa není, a socket, který se spojuje se serverem, musí existovat dřív. Jde tu o dvě různé adresy a jen jedna z nich může být zvolena lokálně.

Chyba při navazování jmenuje místní adresu

Když OpenVPN hlásí, že nemůže navázat místní adresu, mluví o transportním socketu: koncovém bodu UDP nebo TCP, který nese šifrované spojení k protějšku.

Explicitní direktiva local žádá démony, aby tento socket navázal na konkrétní místní adresu. Adresa musí existovat v síťovém jmenném prostoru, kde proces běží, a musí být přiřaditelná v okamžiku, kdy klient startuje.

Veřejná adresa přeložená na routeru nebo na okraji cloudu není místní adresa, kterou by démon mohl navázat, i když je to adresa, kterou server vidí. Tento rozdíl vysvětluje, proč jeden profil funguje doma a selhává na cloudové instanci. Vysvětluje také, proč přidání veřejné adresy na rozhraní loopback nepomáhá, protože transport by pak vycházel z adresy, na kterou síť nedokáže odpovědět. Před úpravou profilu si přečtěte seznam rozhraní.

Co local a remote skutečně vybírají

remote jmenuje protějšek, se kterým se má spojit. local navazuje bližší konec téhož socketu. nobind nechává operačnímu systému volbu místní adresy i portu, a proto klienti za domácími routery obvykle fungují bez obou direktiv.

Ani jedna direktiva nemá s adresou uvnitř tunelu nic společného.

V kontejneru nebo síťovém jmenném prostoru platí stejné pravidlo s užšími hranicemi: adresy hostitele uvnitř nejsou, takže řádek local zkopírovaný z konfigurace hostitele selže z úplně jiného důvodu než špatná adresa.

ip -brief address show
ip route get 203.0.113.10

Vnitřní adresa přichází ze serveru

Adresa uvnitř tunelu se vyjednává nebo přiděluje po navázání řídicího kanálu. U dynamického poolu ji server rozhodne při připojení, u konfigurace specifické pro klienta může být pevná pro každou identitu.

Zapsat local s vnitřní adresou neznamená požádat server, aby tuto adresu přidělil. V nejlepším případě navázání selže; v nejhorším klient najde nesouvisející adresu hostitele se stejnou hodnotou a začne ji pro transport používat.

Rozhraní, která je třeba číst, jsou také jiná. Parametry ifconfig a konfigurace poolu popisují vnitřek, zatímco remote, local, proto a nobind popisují vnějšek. Když se oba seznamy drží odděleně, vysvětlí to téměř každý matoucí příklad, který na fóru najdete. Manuál OpenVPN 2.6 je proto dokumentuje v oddělených oddílech.

Past: plný tunel, který zachytí vlastní transport

Jakmile tunel běží a nese výchozí trasu, pakety, které ho udržují, se do něj nesmějí směrovat. To je problém směrování, ne adresování, a démon ho řeší instalací konkrétnější trasy k adrese samotného serveru přes původní bránu.

Pokud transport připevníte ke konkrétní místní adrese a později změníte cestu, kterou tato adresa používá, vnější spojení se může ztratit, zatímco vnitřek zůstává nakonfigurovaný. Tunel dál hlásí, že je připojený, protože vnitřek je v pořádku. Rozbitý je jen transport, a proto se logy čtou jako protimluvy.

Příznaky pak vypadají jako tunel, který se připojí a zamrzne, nebo jako tunel, který se ve smyčce znovu připojuje bez užitečné chyby. Zkontrolujte trasu k adrese protějšku dřív, než zkontrolujete cokoli uvnitř tunelu, a ověřte, že místní adresa, kterou jste navázali, stále patří rozhraní, které jste očekávali.

Návyk, který zmatku předchází

Přečtěte si každou adresu v profilu a před úpravou rozhodněte, do které vrstvy patří.

Pokud jmenuje vzdálený konec transportu nebo navazuje jeho bližší konec, je to vnější adresa a musí existovat před startem. Pokud popisuje, co se děje uvnitř tunelu, přichází ze serveru nebo z topologie a žádná místní direktiva ji nenahradí.

Zapište oba seznamy do nasazovacích poznámek vedle profilu. Příští diagnostická session pak začne vrstvou, ne dohadem.