Zašto odgovor OpenVPN-a preko UDP-a izlazi s pogrešne adrese

OpenVPN klijent bira jednu adresu, server odgovara s druge, a tunel se nikad ne podigne. Server log pokazuje da paket stiže, a snimak pokazuje da odgovor izlazi, pa se kvar pripisuje klijentu. Na hostu s više interfejsa ili s više adresa na jednom interfejsu dvije strane se jednostavno ne slažu oko toga koja adresa je u upotrebi. Odgovor je ispravan na IP sloju, ali mnogi klijenti odbacuju datagram čiji izvor nije adresa kojoj su se obratili.

Šta klijent vidi kada se izvor promijeni

UDP utičnica koja nije vezana za određenu lokalnu adresu nema fiksni izvor, pa jezgro bira jedan u trenutku slanja. Taj izbor dolazi iz pretrage rute prema adresi klijenta, a izvor postaje adresa interfejsa koji pretraga odabere. Na mašini s jednim interfejsom izbor je nevidljiv; na hostu s adresom za upravljanje, javnom adresom i sekundarnom adresom na istoj mrežnoj kartici zavisi od metrika ruta i politike. Rutiranje po politici čini neusklađenost vjerovatnijom, a ne manje vjerovatnom, jer pravilo može odabrati uzvodni link do kojeg klijent nikad nije stigao. Dovoljna je podrazumijevana ruta naučena od jednog provajdera plus pravilo izvora koje pokazuje na drugi.

Klijenti koji filtriraju odgovore i praćenje veza koje očekuje tačnu četvorku i izvor odbaciće odgovor bez korisne poruke. Tunel tada istekne kao da ništa nije stiglo, i zato se to pogrešno pripisuje problemu firewall-a na strani klijenta. Snimak napravljen samo na serveru potvrđuje grešku umjesto da je objasni, jer odgovor zaista izlazi. Uporedite izvor odgovora s adresom koju je klijent birao prije nego što promijenite bilo šta drugo.

Šta opcija multihome zapravo radi

Direktiva se piše kao multihome u konfiguracijskoj datoteci i kao --multihome na komandnoj liniji, i ona čini da UDP server odgovara s adrese do koje je stigao paket klijenta. Jezgro isporučuje originalnu odredišnu adresu kao dodatne podatke pri prijemu, a OpenVPN koristi tu vrijednost kao izvor odgovora. Tako server koji sluša na džoker adresi, local 0.0.0.0 za IPv4 ili njegov IPv6 ekvivalent, ponaša se kao da je svaki klijent stigao do namjenskog slušača. Klijenti koji su došli preko javne adrese dobijaju odgovore s javne adrese, a klijenti na internoj adresi s te adrese. Ništa drugo na putu paketa se ne pomjera: ruta, pravila filtriranja i konfiguracija tunela ostaju tačno kao što su bili.

To posljednje svojstvo razlog je zašto je opciju sigurno dodati inače ispravnom serveru, a ujedno i razlog zašto ne može popraviti filter koji dozvoljava samo jednu adresu. Paket i dalje mora biti prihvaćen na putu kojim prolazi, pa ispravka izvora mijenja porijeklo odgovora i ništa više. Ona je i samo za UDP: TCP slušač nema ovaj problem u istom obliku, jer se veza identifikuje četvorkom, a ne adresom izvora odgovora.

Kada je fiksna lokalna adresa pogrešno podrazumijevana

Prije nego posegnete za opcijom, provjerite veže li server jednu određenu lokalnu adresu, jer vezani slušač uvijek odgovara s te adrese. To je ispravno za postavljanje s jednim interfejsom i pogrešno čim klijenti legitimno koriste više od jedne adrese. Ako je vezivanje bilo namjerno, odlučite treba li server uopšte prihvatati saobraćaj na dodatnim adresama. Uklanjanje vezivanja povećava izloženost, pa dozvoljene interfejse i izvorne mreže moraju provoditi servis i filter, a ne samo adresa vezivanja.

OpenVPN priručnik ograničava opciju na UDP servere, bilježi dodatnu obradu na putu paketa i navodi koje je platforme podržavaju. Potvrdite to na instaliranom izdanju prije nego što na tome planirate. Gdje nije podržana, alternativa je vezivanje određene adrese ili ispravljanje povratne rute, a oboje su uže promjene nego što se na prvi pogled čini. Slušanje na džoker adresi ima posljedice i izvan odgovora: server na svim adresama dostupan je iz svake mreže na koju je host priključen, a to možda nije izloženost koju je iko namjeravao.

Dokažite izvor odgovora izvana

Testirajte izvana u odnosu na server i zabilježite tačnu adresu i transport koje je klijent koristio prije nego što bilo šta snimite. Tri provjere ispod odgovaraju na tri različita pitanja, a redoslijed je važan.

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

Snimak pokazuje adresu izvora u odgovoru, a to je činjenica na kojoj počiva cijeli tekst. Popis utičnica pokazuje na šta je server zaista vezan, jer džoker slušač i određeni slušač izgledaju isto u konfiguracijskoj datoteci, a ponašaju se različito na mreži. Pretraga rute pokazuje izvor koji bi jezgro odabralo za taj tok, i to objašnjava snimak prije nego što bilo šta promijenite. Ponovite sve tri za IPv4 i IPv6 odvojeno, jer su to odvojeni slušači i odvojene pretrage, a džoker unos za jednu porodicu ne govori ništa o drugoj.

Rutiranje, otkrivanje i filtriranje ostaju odvojeni

Čuvanje izvora odgovora ne instalira odlaznu rutu, ne ažurira dinamički DNS i ne čini da jedna adresna porodica prihvati drugu. Na serveru s više uzvodnih linkova povratni put za svaki izvor mora se namjerno dogovoriti, inače odgovori izlaze kroz interfejs koji filter klijenta nikad nije dozvolio. Isto tako, nova adresa nakon promjene prefiksa mora stići do klijenata kroz otkrivanje i podržani tok ponovnog povezivanja, a ne kroz stari zapis.

Ostavite provjere identiteta servera i provjeru certifikata tačno kakve jesu, jer promijenjena adresa ne opravdava prihvatanje neprovjerenog partnera. Ako odgovor sada izlazi s predviđenog izvora, a tunel i dalje ne radi, smatrajte problem izvora riješenim i idite dalje. Sljedeća uočena greška pripada rutiranju, filtriranju ili autentifikaciji, a ponovna promjena slušača je neće dosegnuti. Upišite izvor odgovora u tiket pored adrese koju je klijent birao, da sljedeća osoba može provjeriti istu činjenicu jednom komandom.