Hvers vegna UDP-svar OpenVPN fer frá röngu vistfangi

OpenVPN biðlari hringir á eitt vistfang, þjónninn svarar frá öðru, og göngin koma aldrei upp. Þjónnarloggið sýnir pakkann berast og skráning sýnir svar fara út, svo bilunin er kennd biðlaranum. Á hýsli með nokkrum tengi, eða nokkrum vistföngum á einu tengi, eru báðir aðilar einfaldlega ósammála um hvaða vistfang er í notkun. Svarið er gilt á IP-laginu, en margir biðlarar henda datagrami þar sem uppruninn er ekki vistfangið sem þeir höfðu samband við.

Hvað biðlarinn sér þegar uppruninn breytist

UDP-socket sem er ekki bundið við ákveðið staðbundið vistfang hefur engan fastan uppruna, svo kjarninn velur einn þegar sent er. Það val kemur frá leiðarleit að vistfangi biðlarans, og uppruninn verður vistfang þess tengis sem leitin velur. Á vél með einu tengi er valið ósýnilegt; á hýsli með stjórnunarvistfang, almennt vistfang og aukavistfang á sama netkorti fer það eftir leiðarmælikvörðum og stefnu. Stefnumiðuð leiðarstýring gerir misræmið líklegra en ekki síður líklegt, því regla getur valið uppstreymistengingu sem biðlarinn náði aldrei. Nóg er að hafa sjálfgefna leið lærða af einum veitanda og upprunareglu sem bendir á annan.

Biðlarar sem sía svör, og tengslarakning sem ætlast til nákvæmra fjórgildis og upprunans, munu henda svarinu án gagnlegrar skilaboða. Þá rennur göngunum út eins og ekkert hafi borist, og þess vegna er þetta ranglega talið eldveggsvandamál á biðlarahlið. Skráning sem tekin er aðeins á þjóninum staðfestir mistökin í stað þess að útskýra þau, því svarið fer sannarlega út. Berið uppruna svarsins saman við vistfangið sem biðlarinn hringdi áður en þið breytið einhverju öðru.

Hvað multihome-valkosturinn gerir í raun

Tilskipunin er skrifuð sem multihome í stillingarskrá og sem --multihome á skipanalínunni, og hún lætur UDP-þjón svara frá því vistfangi sem pakki biðlarans náði. Kjarninn afhendir upprunalega áfangavistfangið sem viðbótargögn við móttöku, og OpenVPN notar það gildi sem uppruna svarsins. Þannig hagar þjónn sem hlustar á algilt vistfang, local 0.0.0.0 fyrir IPv4 eða IPv6 jafngildi þess, sér eins og hver biðlari hafi náð sérstökum hlustanda. Biðlarar sem komu í gegnum almenna vistfangið fá svör frá almenna vistfanginu, og biðlarar á innra vistfangi fá þau frá því. Ekkert annað á slóð pakkans hreyfist: leiðin, síureglurnar og stilling ganganna halda sér nákvæmlega eins og þau voru.

Einmitt þessi síðasta eiginleiki gerir valkostinn öruggan til að bæta við þjón sem virkar að öðru leyti, og er líka ástæðan fyrir því að hann getur ekki lagað síu sem leyfir aðeins eitt vistfang. Pakkinn verður samt að vera samþykktur á þeirri leið sem hann fer, svo upprunaleiðréttingin breytir uppruna svarsins og engu öðru. Hann er líka aðeins fyrir UDP: TCP-hlustandi hefur ekki þetta vandamál í sömu mynd, því tengingin er auðkennd með fjórgildinu en ekki upprunavistfangi svarsins.

Hvenær fast staðbundið vistfang er rangt sjálfgefið gildi

Áður en þið grípið til valkostsins, athugið hvort þjónninn bindur eitt ákveðið staðbundið vistfang, því bundinn hlustandi svarar alltaf frá því vistfangi. Það er rétt fyrir uppsetningu með einu tengi og rangt um leið og biðlarar nota lögmætlega fleiri en eitt vistfang. Ef bindingin var viljandi, ákveðið hvort þjónninn eigi yfirleitt að taka við umferð á fleiri vistföngum. Að fjarlægja bindinguna eykur vá, svo leyfð tengi og upprunanet verða að vera framfylgt af þjónustunni og síunni, ekki aðeins bindivistanum.

OpenVPN viðmiðunin takmarkar valkostinn við UDP-þjóna, getur um viðbótarúrvinnslu á slóð pakkans og skráir hvaða kerfi styðja hann. Staðfestið það á uppsettu útgáfunni áður en þið skipuleggið út frá því. Þar sem hann er ekki studdur er valkosturinn að binda tiltekið vistfang eða laga afturleiðina, og bæði eru þrengri breytingar en þau virðast við fyrstu sýn. Hlustun á algildu vistfangi hefur líka afleiðingar út fyrir svör: þjónn á öllum vistföngum er aðgengilegur frá hverju því neti sem hýslinum er tengt, og það er ef til vill ekki sú vá sem einhver ætlaði sér.

Sannið uppruna svarsins að utan

Prófið utan þjónsins, og skráið nákvæma vistfangið og flutninginn sem biðlarinn notaði áður en þið skráið nokkuð. Þrjú próf hér að neðan svara þremur mismunandi spurningum, og röðin skiptir máli.

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

Skráningin sýnir upprunavistfangið á svarinu, og það er sú staðreynd sem öll greinin hvílir á. Socket-listinn sýnir hvað þjónninn batt í raun, því algildur hlustandi og tiltekinn hlustandi líta eins út í stillingarskrá og hegða sér öðruvísi á netinu. Leiðarleitin sýnir upprunann sem kjarninn myndi velja fyrir þá strauma, og það útskýrir skráninguna áður en þið breytið nokkuð. Endurtakið öll þrjú fyrir IPv4 og IPv6 sitt í hvoru lagi, því þau eru aðskildir hlustendur og aðskildar leitir, og algild færsla fyrir eina fjölskyldu segir ekkert um hina.

Leiðarstýring, uppgötvun og síun halda sér aðskilin

Að varðveita uppruna svarsins setur ekki upp útleið, uppfærir ekki kraftstýrt DNS og fær ekki eina vistfangsfjölskyldu til að taka við annarri. Á þjóni með nokkrum uppstreymistengingum verður að semja viljandi um afturleið hvers uppruna, annars fara svör út um tengi sem sía biðlarans leyfði aldrei. Á sama hátt verður nýtt vistfang eftir forskeytabreytingu að ná til biðlara með uppgötvun og studdu endurtengingarflæðinu, ekki með gömlu færslunni.

Leyfið auðkennisprófunum þjónsins og staðfestingu skírteina að vera nákvæmlega eins og þau eru, því breytt vistfang réttlætir ekki að taka við óstaðfestum mótaðila. Ef svarið fer nú frá fyrirhuguðum uppruna og göngin mistakast samt, lítið á upprunavandamálið sem leyst og haldið áfram. Næsta villa sem sjá má tilheyrir leiðarstýringu, síun eða auðkenningu, og önnur breyting á hlustandanum nær ekki til hennar. Skrifið uppruna svarsins í miðann við hlið vistfangsins sem biðlarinn hringdi á, svo næsta manneskja geti athugað sömu staðreynd með einni skipun.