Prečo odpoveď OpenVPN cez UDP odchádza z nesprávnej adresy

Klient OpenVPN vytáča jednu adresu, server odpovedá z inej a tunel sa nikdy nezdvihne. Log servera ukazuje prichádzajúci paket a záznam ukazuje odchádzajúcu odpoveď, takže zlyhanie sa zvalí na klienta. Na hostiteľovi s viacerými rozhraniami alebo s viacerými adresami na jednom rozhraní sa obe strany jednoducho nezhodnú na tom, ktorá adresa sa používa. Odpoveď je na vrstve IP platná, napriek tomu mnohí klienti zahodia datagram, ktorého zdrojom nie je adresa, na ktorú sa obrátili.

Čo klient vidí, keď sa zdroj zmení

UDP socket, ktorý nie je zviazaný s konkrétnou miestnou adresou, nemá pevný zdroj, takže jadro jeden vyberie pri odosielaní. Táto voľba vychádza z hľadania trasy k adrese klienta a zdrojom sa stane adresa rozhrania, ktoré hľadanie vyberie. Na stroji s jedným rozhraním je voľba neviditeľná; na hostiteľovi so správcovskou adresou, verejnou adresou a sekundárnou adresou na tej istej sieťovej karte závisí od metrík a politiky smerovania. Smerovanie podľa politík robí nesúlad pravdepodobnejším, nie menej pravdepodobným, pretože pravidlo môže vybrať pripojenie, ku ktorému sa klient nikdy nedostal. Stačí k tomu predvolená trasa naučená od jedného poskytovateľa a pravidlo zdroja ukazujúce na iného.

Klienti, ktorí filtrujú odpovede, a sledovanie spojení, ktoré očakáva presnú štvorcu a zdroj, odpoveď zahodia bez užitočnej správy. Tunel potom vyprší, akoby nič neprišlo, a práve preto sa to mylne považuje za problém brány firewall na strane klienta. Záznam urobený len na serveri chybu potvrdzuje, namiesto toho aby ju vysvetlil, pretože odpoveď naozaj odchádza. Porovnajte zdroj odpovede s adresou, ktorú klient vytáčal, skôr než zmeníte čokoľvek ďalšie.

Čo voľba multihome skutočne robí

Direktíva sa zapisuje ako multihome v konfiguračnom súbore a ako --multihome na príkazovom riadku a núti UDP server odpovedať z adresy, na ktorú paket klienta dorazil. Jadro pri prijímaní odovzdá pôvodnú cieľovú adresu ako doplnkové údaje a OpenVPN túto hodnotu použije ako zdroj odpovede. Server počúvajúci na zástupnej adrese, local 0.0.0.0 pre IPv4 alebo jeho ekvivalent pre IPv6, sa potom správa, akoby každý klient dorazil na vyhradený poslucháč. Klienti, ktorí prišli cez verejnú adresu, dostávajú odpovede z verejnej adresy a klienti na internej adrese z nej. Nič iné na ceste paketu sa nehýbe: trasa, pravidlá filtra a konfigurácia tunela zostávajú presne také, aké boli.

Práve táto posledná vlastnosť robí voľbu bezpečnou na pridanie do inak fungujúceho servera a je aj dôvodom, prečo nedokáže opraviť filter, ktorý povoľuje iba jednu adresu. Paket stále musí byť prijatý na ceste, ktorou ide, takže oprava zdroja mení pôvod odpovede a nič viac. Platí aj len pre UDP: TCP poslucháč nemá tento problém v rovnakej podobe, pretože spojenie sa identifikuje štvorcou, nie adresou zdroja odpovede.

Kedy je pevná miestna adresa nesprávnym predvoleným nastavením

Skôr než siahnete po voľbe, skontrolujte, či server viaže jednu konkrétnu miestnu adresu, pretože zviazaný poslucháč vždy odpovedá z tejto adresy. To je správne pre nasadenie s jedným rozhraním a nesprávne, hneď ako klienti oprávnene používajú viac ako jednu adresu. Ak bolo zviazanie úmyselné, rozhodnite, či má server vôbec prijímať prevádzku na ďalších adresách. Odstránenie zviazania zvyšuje vystavenie, preto povolené rozhrania a zdrojové siete musia presadiť služba a filter, nie iba adresa zviazania.

Referencia OpenVPN obmedzuje voľbu na UDP servery, spomína dodatočné spracovanie na ceste paketu a uvádza, ktoré platformy ju podporujú. Potvrďte to na nainštalovanom vydaní, skôr než s ňou budete počítať. Kde podporovaná nie je, alternatívou je zviazanie konkrétnej adresy alebo oprava spätnej trasy, a oboje je užšia zmena, než sa na prvý pohľad zdá. Počúvanie na zástupnej adrese má dôsledky aj mimo odpovedí: server na všetkých adresách je dostupný z každej siete, ku ktorej je hostiteľ pripojený, a to nemusí byť vystavenie, ktoré niekto zamýšľal.

Dokážte zdroj odpovede zvonku

Testujte zvonku voči serveru a pred akýmkoľvek zachytávaním si zapíšte presnú adresu a transport, ktoré klient použil. Tri sondy nižšie odpovedajú na tri rôzne otázky a poradie 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

Záznam ukazuje zdrojovú adresu v odpovedi, a na tomto fakte stojí celý článok. Výpis socketov ukazuje, čo server skutočne zviazal, pretože zástupný a konkrétny poslucháč vyzerajú v konfiguračnom súbore rovnako a v sieti sa správajú inak. Hľadanie trasy ukazuje zdroj, ktorý by jadro pre tento tok zvolilo, a to vysvetľuje záznam skôr, než čokoľvek zmeníte. Zopakujte všetky tri pre IPv4 a IPv6 zvlášť, pretože ide o samostatné poslucháče a samostatné hľadania a zástupný záznam pre jednu rodinu nehovorí o druhej nič.

Smerovanie, objavovanie a filtrovanie zostávajú oddelené

Zachovanie zdroja odpovede nenainštaluje odchádzajúcu trasu, neaktualizuje dynamické DNS a nespôsobí, že jedna rodina adries prijme druhú. Na serveri s viacerými pripojeniami sa spätná cesta pre každý zdroj musí vedome dohodnúť, inak odpovede odchádzajú rozhraním, ktoré filter klienta nikdy nepovolil. Rovnako nová adresa po zmene prefixu musí ku klientom doraziť cez objavovanie a podporovaný tok opätovného pripojenia, nie cez starý záznam.

Nechajte kontroly identity servera a overovanie certifikátov presne také, aké sú, pretože zmenená adresa neospravedlňuje prijatie neovereného partnera. Ak odpoveď teraz odchádza zo zamýšľaného zdroja a tunel stále zlyháva, považujte problém zdroja za vyriešený a pokračujte. Ďalšia pozorovaná chyba patrí smerovaniu, filtrovaniu alebo autentifikácii a ďalšia zmena poslucháča na ňu nedosiahne. Zapíšte zdroj odpovede do tiketu vedľa adresy, ktorú klient vytáčal, aby si ďalší človek mohol overiť ten istý fakt jediným príkazom.