Zergatik bidaltzen du LAN ostalari batek ARP OpenVPN bezero baten helbidera

LAN ostalari baten eta VPN bezero baten arteko irisgarritasun arazoek sarritan helbide planera berera egiten dute atzera. Eman ostalari horri 10.0.100.0/22-n interfaze bat eta 10.0.100.0-tik 10.0.103.255-ra arteko helbide bakoitza zuzenean konektatutzat hartuko du, 10.0.101.0/24-n isilka jarritako bezero multzoa barne. Erantzuna ez da inoiz bideratzailera joaten, ostalariaren ikuspegitik ez baitago bideratzailerik parte hartzen. Paketea bizilagun bati zuzentzen zaio eta harian eskatzen da.

Mekanismo hori txosten familia oso baten atzean dago: tunela martxan dago, zerbitzariak bide bat du, eta LAN ostalariak oraindik ezin dio bezeroari heldu.

/24 irentsten duen /22

Irakurri aurrizkia tarte gisa, ez kate gisa. /22 batek 1024 helbide ditu, eta 10.0.100.0/22 10.0.100.0-tik 10.0.103.255-ra doa, beraz 10.0.101.0/24-n dagoen multzoa osorik haren barruan dago. Akats honek berrikuspena gainditzen du multzoaren lehen oktetoak LANaren lehen oktetoen desberdinak diruditelako, eta hirugarren oktetoak soilik erakusten du barne hartzea. Idatzi bi tarteak zenbakitan bananduta direla adierazi aurretik.

Barne hartze bera alderantziz ere ager daiteke. Oraingoz inork erabiltzen ez duelako hutsik dirudien multzo bat gune bateko bideratzaile batek iragartzen duen aurrizki baten barruan eror daiteke, eta helbide plana hori erakusten duen dokumentu bakarra da.

Konexio zuzenak ARP esan nahi du, ez bideratzea

/22 interfazea duen ostalari batek 10.0.101.25-era bidaltzen duenean, kernelak helburua interfazearen aurrizkiarekin alderatzen du eta bat-etortzea aurkitzen du. Paketea bizilagun bilaketa bihurtzen da bideratutako paketea izan beharrean, eta Etherneten bizilagun bilaketa helbide horren ARP eskaera da. Helbidea bideratutako ate baten atzean dagoen VPN bezero batena bada, LANeko inongo ostalarik ez du helbide hori, beraz eskaera erantzunik gabe geratzen da eta paketeak baztertu egiten dira. Tunela ez da erruduna, eta bezeroak ez du trafikoa inoiz ikusten.

Horregatik akatsak asimetriko eta noizean behin etena dirudi. VPN ostalaritzak sarritan LANera iristen da bere bide propioak norabide egokia erakusten duelako, LAN ostalariak erantzun ezin duen bitartean, eta ARP sarrera zaharra cachean gordetzen duen edozein gauzak sintoma dirdiratzen du.

TUN, TAP eta bakoitzak zer garraiatzen duen

TUN gailuak IP paketeak garraiatzen ditu, eta TAP gailuak Ethernet markoak garraiatzen ditu. Bideratutako TUN estekak ez du ARP garraiatu behar IP irisgarritasuna emateko, eta horrexegatik goiko erantzunik gabeko eskaera espero da, ez da akats bat. TAPek zubi deliberatu batekin difusio domeinua zabaldu eta ARP funtzionaraz dezake, baina bezeroak ikus dezakeena aldatzen du, marko berera eusten duten muturrak eskatzen ditu, eta sare ereduaren berrantolaketa da, gainjartzen den aurrizki baterako konponketa izan beharrean. Bideratutako inplementazio bat TAPera aldatzea helbide planaren akatsa sendatzeko arazo txikia handiago batekin trukatzea da.

Erregistratu ARP eskaera non agertu zen eta zein sistemak bidali zuen ondorioak atera aurretik. Bidaltzaileak helburuaz zer uste duen esaten dizu, ez tunelak zer egiten duen.

Diseinatu gainjarri ezin den multzo bat

Aukeratu multzo bat konektatutako aurrizki guztietatik eta iragarritako gune aurrizki guztietatik kanpo, gero gehitu bi norabideetan irisgarri egiten duten bideak. Planaren erabili gabeko zatian 10.8.0.0/24 bezalako tarte bat erraza da pentsatzen, eta hara iritsi behar duen LANak VPN zerbitzarira seinalatzen duen bide estatiko bat jasotzen du. Aldatu batera esleipena, iragarritako bideak, onartutako iturburu helbideak eta suebakiko arauak, diseinu bakarra deskribatzen baitute, ez lau ezarpen.

Zerbitzariko Source NATek multzoa LANetik bideragarri den helbide baten atzean ezkuta dezake, eta migrazio tresna legitimoa da. Iturburua ere berridazten du, beraz LANak konexioak bezero indibidualei egotzita eta bezero bakoitzeko arauak aplikatzeko gaitasuna galtzen du.

Onarpenarako, erabili benetako bezeroari benetan esleitutako helbidea eta LAN ostalari batetik egindako aplikazio eskaera erreala, gero baieztatu erantzuna planifikatutako ateari jarraitzen diola, haria ez ezik.