Kodėl OpenVPN UDP atsakymas išeina iš neteisingo adreso

OpenVPN klientas renkasi vieną adresą, serveris atsako iš kito, ir tunelis niekada nepasikelia. Serverio žurnalas rodo atvykstantį paketą, o įrašas rodo išeinantį atsakymą, todėl gedimas priskiriamas klientui. Hoste su keliais sąsajomis arba keliais adresais vienoje sąsajoje abi pusės tiesiog nesutaria, kuris adresas naudojamas. Atsakymas galioja IP lygmenyje, tačiau daugelis klientų atmeta datagramą, kurio šaltinis nėra adresas, su kuriuo jie susisiekė.

Ką klientas mato, kai šaltinis pasikeičia

UDP lizdas, nesusietas su konkrečiu vietiniu adresu, neturi pastovaus šaltinio, todėl branduolys jį parenka siuntimo metu. Šis pasirinkimas kyla iš maršruto paieškos link kliento adreso, o šaltiniu tampa sąsajos, kurią paieška pasirenka, adresas. Vienos sąsajos mašinoje pasirinkimas nematomas; hoste su valdymo adresu, viešu adresu ir antriniu adresu toje pačioje tinklo kortelėje jis priklauso nuo maršruto metrikų ir politikos. Politika pagrįstas maršrutizavimas neatitikimą daro labiau tikėtiną, o ne mažiau, nes taisyklė gali pasirinkti viršutinę jungtį, kurios klientas niekada nepasiekė. Pakanka numatytojo maršruto, išmokto iš vieno tiekėjo, ir šaltinio taisyklės, nukreiptos į kitą.

Klientai, filtruojantys atsakymus, ir ryšių sekimas, kuris tikisi tikslaus ketverto ir šaltinio, atmes atsakymą be naudingos žinutės. Tada tunelis baigiasi tarsi nieko nebūtų atvykę, ir būtent todėl tai klaidingai laikoma kliento pusės užkardos problema. Įrašas, padarytas tik serveryje, patvirtina klaidą, o ne paaiškina ją, nes atsakymas tikrai išeina. Palyginkite atsakymo šaltinį su adresu, kuriuo klientas skambino, prieš ką nors keisdami.

Ką iš tikrųjų daro parinktis multihome

Nurodymas rašomas kaip multihome konfigūracijos faile ir kaip --multihome komandinėje eilutėje, ir jis verčia UDP serverį atsakyti iš adreso, kurį pasiekė kliento paketas. Branduolys priimdamas perduoda pradinį paskirties adresą kaip papildomus duomenis, o OpenVPN naudoja tą reikšmę kaip atsakymo šaltinį. Taip serveris, klausantis bendrojo adreso, local 0.0.0.0 IPv4 arba jo IPv6 atitikmuo, elgiasi taip, tarsi kiekvienas klientas būtų pasiekęs atskirą klausytoją. Klientai, atėję per viešą adresą, gauna atsakymus iš viešo adreso, o vidiniame adrese esantys klientai – iš to adreso. Niekas kitas paketo kelyje nejuda: maršrutas, filtro taisyklės ir tunelio konfigūracija lieka tiksliai tokie, kokie buvo.

Būtent ši paskutinė savybė daro parinktį saugią pridėti prie kitu atžvilgiu veikiančio serverio, ir ji taip pat yra priežastis, kodėl ji negali pataisyti filtro, leidžiančio tik vieną adresą. Paketas vis tiek turi būti priimtas tame kelyje, kuriuo eina, todėl šaltinio pataisa keičia atsakymo kilmę ir nieko daugiau. Ji skirta tik UDP: TCP klausytojas neturi šios problemos ta pačia forma, nes ryšys identifikuojamas ketvertu, o ne atsakymo šaltinio adresu.

Kada fiksuotas vietinis adresas yra neteisinga numatytoji reikšmė

Prieš imdamiesi parinkties, patikrinkite, ar serveris sieja vieną konkretų vietinį adresą, nes susietas klausytojas visada atsako iš to adreso. Tai teisinga diegimui su viena sąsaja ir neteisinga, kai tik klientai teisėtai naudoja daugiau nei vieną adresą. Jei susiejimas buvo sąmoningas, nuspręskite, ar serveris apskritai turi priimti srautą papildomais adresais. Susiejimo pašalinimas padidina ekspoziciją, todėl leidžiamas sąsajas ir šaltinio tinklus turi užtikrinti paslauga ir filtras, o ne vien susiejimo adresas.

OpenVPN žinynas riboja parinktį UDP serveriams, pažymi papildomą apdorojimą paketo kelyje ir nurodo, kurios platformos ją palaiko. Patvirtinkite tai įdiegtoje versijoje prieš planuodami pagal ją. Kur ji nepalaikoma, alternatyva yra susieti konkretų adresą arba pataisyti grįžimo maršrutą, ir abu yra siauresni pakeitimai, nei atrodo iš pirmo žvilgsnio. Klausymasis bendruoju adresu turi pasekmių ir už atsakymų ribų: serveris visais adresais pasiekiamas iš kiekvieno tinklo, prie kurio prijungtas hostas, ir tai gali būti ne ta ekspozicija, kurią kas nors turėjo omenyje.

Įrodykite atsakymo šaltinį iš išorės

Testuokite už serverio ribų ir užsirašykite tikslų adresą bei transportą, kuriuos naudojo klientas, prieš ką nors įrašydami. Trys patikros žemiau atsako į tris skirtingus klausimus, ir tvarka yra svarbi.

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

Įrašas rodo atsakymo šaltinio adresą, ir šiuo faktu remiasi visas straipsnis. Lizdų sąrašas rodo, ką serveris iš tikrųjų susiejo, nes bendrasis ir konkretus klausytojas konfigūracijos faile atrodo vienodai, o tinkle elgiasi skirtingai. Maršruto paieška rodo šaltinį, kurį branduolys pasirinktų tam srautui, ir tai paaiškina įrašą prieš ką nors keičiant. Pakartokite visus tris atskirai IPv4 ir IPv6, nes tai atskiri klausytojai ir atskiros paieškos, o vienos šeimos bendrasis įrašas nieko nesako apie kitą.

Maršrutizavimas, aptikimas ir filtravimas lieka atskiri

Atsakymo šaltinio išsaugojimas neįdiegia išeinančio maršruto, neatnaujina dinaminio DNS ir nepriverčia vienos adresų šeimos priimti kitos. Serveryje su keliomis viršutinėmis jungtimis kiekvieno šaltinio grįžimo kelias turi būti sąmoningai suderintas, kitaip atsakymai išeina sąsaja, kurios kliento filtras niekada neleido. Taip pat naujas adresas po priešdėlio pakeitimo turi pasiekti klientus per aptikimą ir palaikomą prisijungimo iš naujo srautą, o ne per seną įrašą.

Palikite serverio tapatybės patikras ir sertifikatų tikrinimą tiksliai tokius, kokie jie yra, nes pasikeitęs adresas nepateisina nepatikrinto partnerio priėmimo. Jei atsakymas dabar išeina iš numatyto šaltinio, o tunelis vis tiek nepavyksta, laikykite šaltinio problemą išspręsta ir eikite toliau. Kita pastebėta klaida priklauso maršrutizavimui, filtravimui arba autentifikacijai, ir dar kartą pakeistas klausytojas jos nepasieks. Įrašykite atsakymo šaltinį į bilietą šalia adreso, kuriuo klientas skambino, kad kitas žmogus galėtų patikrinti tą patį faktą viena komanda.