Zakaj odgovor UDP OpenVPN odide z napačnega naslova

Odjemalec OpenVPN pokliče en naslov, strežnik odgovori z drugega in tunel se nikoli ne dvigne. Dnevnik strežnika kaže prihajajoči paket, posnetek pa kaže odhajajoči odgovor, zato se napaka pripiše odjemalcu. Na gostitelju z več vmesniki ali z več naslovi na enem vmesniku se strani preprosto ne strinjata glede tega, kateri naslov se uporablja. Odgovor je na ravni IP veljaven, a mnogi odjemalci zavržejo datagram, katerega vir ni naslov, s katerim so vzpostavili stik.

Kaj odjemalec vidi, ko se vir spremeni

Vtičnica UDP, ki ni vezana na določen krajevni naslov, nima stalnega vira, zato jedro enega izbere ob pošiljanju. Ta izbira izhaja iz iskanja poti proti naslovu odjemalca, vir pa postane naslov vmesnika, ki ga iskanje izbere. Na stroju z enim vmesnikom je izbira nevidna; na gostitelju z naslovom za upravljanje, javnim naslovom in sekundarnim naslovom na isti omrežni kartici je odvisna od meritev in usmerjevalne politike. Usmerjanje na podlagi politik naredi neskladje bolj verjetno, ne manj, ker lahko pravilo izbere nadrejeno povezavo, do katere odjemalec ni nikoli prišel. Dovolj sta privzeta pot, naučena pri enem ponudniku, in pravilo vira, ki kaže na drugega.

Odjemalci, ki filtrirajo odgovore, in sledenje povezavam, ki pričakuje natančen četverček in vir, bodo odgovor zavrgli brez koristnega sporočila. Tunel nato poteče, kot da ne bi nič prispelo, in zato se to napačno razume kot težava požarnega zidu na strani odjemalca. Posnetek, zajet samo na strežniku, napako potrdi, namesto da bi jo pojasnil, ker odgovor res odide. Primerjajte vir odgovora z naslovom, ki ga je odjemalec poklical, preden spremenite kar koli drugega.

Kaj možnost multihome v resnici naredi

Direktiva se zapiše kot multihome v konfiguracijski datoteki in kot --multihome v ukazni vrstici, in poskrbi, da strežnik UDP odgovori z naslova, do katerega je prispel paket odjemalca. Jedro ob prejemu preda izvirni ciljni naslov kot dodatne podatke, OpenVPN pa to vrednost uporabi kot vir odgovora. Tako se strežnik, ki posluša na splošnem naslovu, local 0.0.0.0 za IPv4 ali njegova različica IPv6, obnaša, kot da bi vsak odjemalec dosegel namenski poslušalec. Odjemalci, ki so prišli skozi javni naslov, dobijo odgovore z javnega naslova, odjemalci na notranjem naslovu pa z njega. Nič drugega na poti paketa se ne premakne: pot, pravila filtra in konfiguracija tunela ostanejo natanko takšni, kot so bili.

Prav ta zadnja lastnost naredi možnost varno za dodajanje na sicer delujoč strežnik, in je tudi razlog, da ne more popraviti filtra, ki dovoljuje samo en naslov. Paket mora biti še vedno sprejet na poti, po kateri gre, zato popravek vira spremeni izvor odgovora in nič več. Velja tudi samo za UDP: poslušalec TCP te težave nima v enaki obliki, ker se povezava prepozna po četverčku in ne po naslovu vira odgovora.

Kdaj je nespremenljiv krajevni naslov napačna privzeta vrednost

Preden posežete po možnosti, preverite, ali strežnik veže en določen krajevni naslov, ker vezan poslušalec vedno odgovori s tega naslova. To je pravilno za postavitev z enim vmesnikom in napačno takoj, ko odjemalci zakonito uporabljajo več kot en naslov. Če je bila vezava namerna, odločite, ali naj strežnik sploh sprejema promet na dodatnih naslovih. Odstranitev vezave poveča izpostavljenost, zato morata dovoljene vmesnike in izvorna omrežja uveljaviti storitev in filter, ne le naslov vezave.

Referenca OpenVPN omejuje možnost na strežnike UDP, omenja dodatno obdelavo na poti paketa in beleži, katere platforme jo podpirajo. To potrdite na nameščeni izdaji, preden načrtujete na njeni podlagi. Kjer ni podprta, je alternativa vezava določenega naslova ali popravek povratne poti, in oboje so ožje spremembe, kot se zdi na prvi pogled. Poslušanje na splošnem naslovu ima posledice tudi onkraj odgovorov: strežnik na vseh naslovih je dosegljiv iz vsakega omrežja, na katerega je gostitelj priključen, in to morda ni izpostavljenost, ki jo je kdo nameraval.

Dokažite vir odgovora od zunaj

Preskusite zunaj strežnika in pred kakršnim koli zajemom zabeležite natančen naslov in prenos, ki ju je uporabil odjemalec. Spodnji trije preskusi odgovarjajo na tri različna vprašanja, vrstni red pa je pomemben.

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

Posnetek pokaže naslov vira v odgovoru, in na tem dejstvu stoji ves članek. Seznam vtičnic pokaže, kaj je strežnik v resnici vezal, ker sta splošni in določeni poslušalec v konfiguracijski datoteki videti enako in se v omrežju obnašata drugače. Iskanje poti pokaže vir, ki bi ga jedro izbralo za ta tok, in to pojasni posnetek, preden karkoli spremenite. Vse tri ponovite za IPv4 in IPv6 ločeno, ker gre za ločene poslušalce in ločena iskanja, in splošen vnos za eno družino ne pove ničesar o drugi.

Usmerjanje, odkrivanje in filtriranje ostanejo ločeni

Ohranjanje vira odgovora ne namesti odhodne poti, ne posodobi dinamičnega DNS in ne povzroči, da bi ena naslovna družina sprejela drugo. Na strežniku z več nadrejenimi povezavami je treba povratno pot za vsak vir zavestno dogovoriti, sicer odgovori odidejo skozi vmesnik, ki ga filter odjemalca ni nikoli dovolil. Prav tako mora nov naslov po spremembi predpone priti do odjemalcev prek odkrivanja in podprtega toka ponovne povezave, ne prek starega zapisa.

Pustite preverjanja identitete strežnika in preverjanje potrdil natanko takšna, kot so, ker spremenjen naslov ne upravičuje sprejema nepreverjenega partnerja. Če odgovor zdaj odide z načrtovanega vira in tunel še vedno ne deluje, imejte težavo vira za rešeno in pojdite naprej. Naslednja opažena napaka spada k usmerjanju, filtriranju ali preverjanju pristnosti, in ponovna sprememba poslušalca je ne bo dosegla. Zapišite vir odgovora v zahtevek ob naslovu, ki ga je poklical odjemalec, da bo naslednja oseba lahko preverila isto dejstvo z enim ukazom.