Proč odpověď OpenVPN po UDP odchází ze špatné adresy

Klient OpenVPN vytáčí jednu adresu, server odpovídá z jiné a tunel se nikdy nezvedne. Log serveru ukazuje přicházející paket a zachycený provoz ukazuje odcházející odpověď, takže se selhání svede na klienta. Na hostiteli s několika rozhraními nebo s několika adresami na jednom rozhraní se obě strany prostě neshodnou na tom, která adresa se používá. Odpověď je na vrstvě IP platná, přesto mnoho klientů zahodí datagram, jehož zdroj není adresa, na kterou se obrátili.

Co klient vidí, když se zdroj změní

UDP socket, který není svázán s konkrétní místní adresou, nemá pevný zdroj, takže jádro jeden vybere v okamžiku odeslání. Tato volba vychází z hledání trasy k adrese klienta a zdrojem se stane adresa rozhraní, které hledání vybere. Na stroji s jedním rozhraním je volba neviditelná; na hostiteli se správcovskou adresou, veřejnou adresou a sekundární adresou na stejné síťové kartě závisí na metrikách a politice směrování. Směrování podle politik činí nesoulad pravděpodobnějším, nikoli méně pravděpodobným, protože pravidlo může vybrat přípojku, ke které se klient nikdy nedostal. Stačí k tomu výchozí trasa naučená od jednoho poskytovatele a pravidlo zdroje ukazující na jiného.

Klienti, kteří filtrují odpovědi, a sledování spojení, které očekává přesnou čtveřici a zdroj, odpověď zahodí bez užitečné zprávy. Tunel pak vyprší, jako by nic nepřišlo, a právě proto se to mylně považuje za problém firewallu na straně klienta. Zachytávání pořízené jen na serveru chybu potvrzuje, místo aby ji vysvětlilo, protože odpověď opravdu odchází. Porovnejte zdroj odpovědi s adresou, kterou klient vytáčel, než změníte cokoli dalšího.

Co volba multihome skutečně dělá

Direktiva se zapisuje jako multihome v konfiguračním souboru a jako --multihome na příkazovém řádku a nutí UDP server odpovídat z adresy, na kterou paket klienta dorazil. Jádro při příjmu předává původní cílovou adresu jako doplňková data a OpenVPN tuto hodnotu použije jako zdroj odpovědi. Server naslouchající na zástupné adrese, local 0.0.0.0 pro IPv4 nebo jeho ekvivalentu pro IPv6, se pak chová, jako by každý klient dorazil na vyhrazený posluchač. Klienti, kteří přišli přes veřejnou adresu, dostávají odpovědi z veřejné adresy a klienti na vnitřní adrese z ní. Nic jiného na cestě paketu se nehýbe: trasa, pravidla filtru i konfigurace tunelu zůstávají přesně tak, jak byly.

Právě tato poslední vlastnost je důvod, proč je volba bezpečná pro přidání do jinak funkčního serveru, a také důvod, proč nedokáže opravit filtr, který povoluje jen jednu adresu. Paket stále musí být přijat na cestě, kterou jde, takže oprava zdroje mění původ odpovědi a nic víc. Je také jen pro UDP: TCP posluchač nemá tento problém ve stejné podobě, protože spojení se identifikuje čtveřicí, nikoli adresou zdroje odpovědi.

Kdy je pevná místní adresa špatné výchozí nastavení

Než sáhnete po volbě, zkontrolujte, zda server váže jednu konkrétní místní adresu, protože svázaný posluchač vždy odpovídá z této adresy. To je správné pro nasazení s jedním rozhraním a špatné, jakmile klienti oprávněně používají více než jednu adresu. Pokud bylo svázání záměrné, rozhodněte, zda má server vůbec přijímat provoz na dalších adresách. Odebrání svázání zvyšuje vystavení, takže povolená rozhraní a zdrojové sítě musí vynutit služba a filtr, ne jen adresa svázání.

Reference OpenVPN omezuje volbu na UDP servery, zmiňuje dodatečné zpracování na cestě paketu a uvádí, které platformy ji podporují. Potvrďte to na nainstalovaném vydání, než s ní budete počítat. Kde podporována není, alternativou je svázání konkrétní adresy nebo oprava zpětné trasy, a obojí je užší změna, než se na první pohled zdá. Naslouchání na zástupné adrese má důsledky i mimo odpovědi: server na všech adresách je dostupný z každé sítě, ke které je hostitel připojen, a to nemusí být vystavení, které někdo zamýšlel.

Dokažte zdroj odpovědi zvenčí

Testujte zvenčí vůči serveru a před jakýmkoli zachytáváním si poznamenejte přesnou adresu a přenos, které klient použil. Tři sondy níže odpovídají na tři různé otázky a pořadí má význam.

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

Zachytávání ukazuje zdrojovou adresu v odpovědi, což je fakt, na kterém stojí celý článek. Výpis socketů ukazuje, co server skutečně svázal, protože zástupný a konkrétní posluchač vypadají v konfiguračním souboru stejně a v síti se chovají jinak. Hledání trasy ukazuje zdroj, který by jádro pro tento tok zvolilo, a to vysvětluje zachytávání dřív, než cokoli změníte. Zopakujte všechny tři pro IPv4 a IPv6 zvlášť, protože jde o samostatné posluchače a samostatná hledání a zástupný záznam pro jednu rodinu neříká o druhé nic.

Směrování, objevování a filtrování zůstávají oddělené

Zachování zdroje odpovědi nenainstaluje odchozí trasu, neaktualizuje dynamické DNS ani nezpůsobí, že jedna rodina adres přijme druhou. Na serveru s několika přípojkami se zpětná cesta pro každý zdroj musí vědomě dohodnout, jinak odpovědi odcházejí rozhraním, které filtr klienta nikdy nepovolil. Stejně tak nová adresa po změně prefixu musí ke klientům dorazit přes objevování a podporovaný tok opětovného připojení, ne přes starý záznam.

Nechte kontroly identity serveru a ověřování certifikátů přesně tak, jak jsou, protože změněná adresa neospravedlňuje přijetí neověřeného protějšku. Pokud odpověď nyní odchází ze zamýšleného zdroje a tunel stále selhává, považujte problém zdroje za vyřešený a jděte dál. Příští pozorovaná chyba patří směrování, filtrování nebo autentizaci a další změna posluchače na ni nedosáhne. Zapište zdroj odpovědi do tiketu vedle adresy, kterou klient vytáčel, aby příští člověk mohl stejný fakt ověřit jedním příkazem.