Kodėl LAN hostas siunčia ARP OpenVPN kliento adresui

Pasiekiamumo problemos tarp LAN hosto ir VPN kliento dažnai veda atgal prie paties adresų plano. Suteikite tam hostui sąsają 10.0.100.0/22 tinkle ir jis kiekvieną adresą nuo 10.0.100.0 iki 10.0.103.255 laikys tiesiogiai prijungtu, įskaitant klientų telkinį, tyliai patalpintą 10.0.101.0/24. Atsakymas niekada neina maršrutizatoriui, nes hosto požiūriu joks maršrutizatorius nedalyvauja. Paketas adresuotas kaimynui ir prašomas laidu.

Šis mechanizmas slypi už visos šeimos pranešimų: tunelis veikia, serveris turi maršrutą, o LAN hostas vis tiek negali pasiekti kliento.

/22 prefiksas, kuris praryja /24

Skaitykite prefiksą kaip diapazoną, o ne kaip eilutę. /22 prefikse yra 1024 adresai, o 10.0.100.0/22 tęsiasi nuo 10.0.100.0 iki 10.0.103.255, todėl telkinys 10.0.101.0/24 yra visiškai jo viduje. Klaida išlieka peržiūroje, nes pirmieji telkinio oktetai atrodo kitaip nei pirmieji LAN oktetai, ir tik trečiasis oktetas atskleidžia įterpimą. Užrašykite abu diapazonus skaičiais, prieš paskelbdami juos atskirais.

Tas pats įterpimas gali pasireikšti ir atvirkščiai. Telkinys, kuris atrodo laisvas, nes dabar jo niekas nenaudoja, vis tiek gali patekti į prefiksą, kurį skelbia koks nors vietos maršrutizatorius, o adresų planas yra vienintelis dokumentas, kuris tai parodo.

Tiesioginis ryšys reiškia ARP, o ne maršrutizavimą

Kai hostas su /22 sąsaja siunčia į 10.0.101.25, branduolys palygina paskirties adresą su sąsajos prefiksu ir randa atitikimą. Paketas tampa kaimyno paieška, o ne maršrutizuotu paketu, o Ethernet tinkle kaimyno paieška yra ARP užklausa tam adresui. Jei adresas priklauso VPN klientui už maršrutizuotų vartų, joks LAN hostas jo neturi, todėl užklausa lieka neatsakyta, o paketai išmetami. Tunelis nekaltas, o klientas niekada nemato srauto.

Štai kodėl gedimas atrodo asimetriškas ir kartais su pertraukomis. VPN hostas dažnai pasiekia LAN, nes jo paties maršrutai rodo tinkama kryptimi, o LAN hostas negali atsakyti, ir bet koks pasenusio ARP įrašo talpinimas verčia simptomą mirgėti.

TUN, TAP ir ką kiekvienas neša

TUN įrenginys neša IP paketus, o TAP įrenginys neša Ethernet kadrus. Maršrutizuota TUN jungtis neturi nešti ARP, kad būtų užtikrintas IP pasiekiamumas, ir būtent todėl aukščiau esanti neatsakyta užklausa yra laukiama, o ne sugedusi. TAP su tyčia sukurtu tiltu gali išplėsti transliacijos domeną ir priversti ARP veikti, bet tai keičia, ką klientas mato, reikalauja galinių taškų, palaikančių tą patį kadravimą, ir yra tinklo modelio pertvarka, o ne sutampančio prefikso taisymas. Maršrutizuoto diegimo perjungimas į TAP, siekiant išgydyti adresų plano klaidą, mažą problemą iškeičia į didesnę.

Užsirašykite, kur atsirado ARP užklausa ir kuri sistema ją išsiuntė, prieš darydami išvadas. Siuntėjas jums sako, ką mano apie paskirties adresą, o ne ką daro tunelis.

Suprojektuokite telkinį, kuris negali persidengti

Pasirinkite telkinį už kiekvieno prijungto prefikso ir kiekvieno skelbiamo vietos prefikso, tada pridėkite maršrutus, kurie padaro jį pasiekiamą abiem kryptimis. Diapazonas kaip 10.8.0.0/24 nenaudojamoje plano dalyje yra lengvai apgalvojamas, o LAN, kuriam reikia jį pasiekti, gauna statinį maršrutą, nukreiptą į VPN serverį. Keiskite kartu paskirstymą, skelbiamus maršrutus, leidžiamus šaltinio adresus ir ugniasienės taisykles, nes jie apibūdina vieną projektą, o ne keturis nustatymus.

Source NAT serveryje gali paslėpti telkinį už adreso, pasiekiamo maršrutu iš LAN, ir tai yra teisėta migracijos priemonė. Jis taip pat perrašo šaltinį, todėl LAN praranda galimybę priskirti ryšius atskiriems klientams ir taikyti taisykles pagal klientą.

Priėmimui naudokite tikrąjį klientui faktiškai priskirtą adresą ir tikrą programos užklausą iš LAN hosto, tada patvirtinkite, kad atsakymas eina per suplanuotus vartus, o ne laidu.