LAN хост яагаад OpenVPN клиентийн хаяг руу ARP илгээдэг вэ

LAN хост ба VPN клиентийн хоорондын хүртээмжийн асуудал ихэвчлэн хаягийн төлөвлөгөө рүү буцаж хөтөлдөг. Тэр хостод 10.0.100.0/22 дээр интерфэйс өгвөл 10.0.100.0-аас 10.0.103.255 хүртэлх бүх хаягийг шууд холбогдсон гэж үзнэ, үүнд 10.0.101.0/24 дээр чимээгүй байрласан клиентийн санг оруулав. Хариулт хэзээ ч чиглүүлэгч рүү явдаггүй, учир нь хостодын өнцгөөс ямар ч чиглүүлэгч оролцохгүй. Багц нь хөрш рүү хаяглагдаж, утсан дээр асуудаг.

Энэ механизм бүхэл бүтэн тайлангийн гэр бүлийн цаана байдаг: туннель ажиллаж, серверт маршрут байгаа ч LAN хост клиент рүү хүрч чадахгүй хэвээр.

/24-ийг залгидаг /22

Префиксийг муж гэж унш, тэмдэгт мөр гэж биш. /22 префикс 1024 хаяг агуулдаг бөгөөд 10.0.100.0/22 нь 10.0.100.0-аас 10.0.103.255 хүртэл үргэлжилдэг тул 10.0.101.0/24 дээрх сан бүхэлдээ дотор нь оршдог. Алдаа нь хяналтыг даван гардаг, учир нь сангийн эхний октетууд LAN-ын эхний октетуудаас өөр харагддаг ба зөвхөн гурав дахь октет л дотор байгааг илчилдэг. Хоёр мужийг тоогоор бичиж, дараа нь тусдаа гэж зарла.

Мөн ижил дотор байх нь эсрэгээр илэрч болно. Одоо хэн ч ашиглахгүй байгаа тул чөлөөтэй харагдах сан нь зарим сайтын чиглүүлэгчийн зарласан префикс дотор орж болох бөгөөд хаягийн төлөвлөгөө л үүнийг харуулдаг цорын ганц баримт бичиг юм.

Шууд холболт гэдэг нь ARP, чиглүүлэлт биш

/22 интерфэйстэй хост 10.0.101.25 руу илгээхэд цөм нь очих хаягийг интерфэйсийн префикстэй харьцуулж, тохирлыг олдог. Багц нь чиглүүлэгдсэн багц биш харин хөршийн хайлт болдог бөгөөд Ethernet дээр хөршийн хайлт нь тухайн хаяг руу ARP хүсэлт юм. Хэрэв хаяг нь чиглүүлэгдсэн гарцын ард байгаа VPN клиентэд хамаарах бол LAN дээрх ямар ч хост түүнийг эзэмшихгүй тул хүсэлт хариулалгүй үлдэж, багцууд хаягдана. Туннель буруугүй бөгөөд клиент трафикийг хэзээ ч хардаггүй.

Тиймээс эвдрэл нь тэгш бус, заримдаа тасалдалтай харагддаг. VPN хост нь өөрийн маршрутууд зөв зүг рүү заасан тул LAN руу ихэвчлэн хүрдэг бол LAN хост хариулж чадахгүй, хуучин ARP бичлэгийг кэшлэсэн бүхэн шинж тэмдгийг анивчихад хүргэдэг.

TUN, TAP ба тус бүр юу дамжуулдаг

TUN төхөөрөмж IP багц, TAP төхөөрөмж Ethernet хүрээ дамжуулдаг. Чиглүүлэгдсэн TUN холбоос IP хүртээмжийг хангахад ARP дамжуулах шаардлагагүй бөгөөд яг ийм учраас дээрх хариулалгүй хүсэлт нь хүлээгдэж буй зүйл бөгөөд эвдрэл биш юм. TAP нь зориудын гүүртэй бол broadcast домэйныг өргөтгөж, ARP-г ажиллуулж чадна, гэхдээ клиент юу харж болохыг өөрчилдөг, ижил хүрээлэлтийг дэмждэг төгсгөлийн цэгүүдийг шаарддаг бөгөөд давхцаж буй префиксийн засвар биш харин сүлжээний загварын дахин зохион байгуулалт юм. Хаягийн төлөвлөгөөний алдааг эмчлэхээр чиглүүлэгдсэн байршуулалтыг TAP руу шилжүүлэх нь жижиг асуудлыг томоор сольдог.

Дүгнэлт хийхээс өмнө ARP хүсэлт хаана гарч ирсэн, аль систем илгээснийг тэмдэглэ. Илгээгч нь очих хаягийн талаар юу гэж боддогоо хэлдэг, туннель юу хийдгийг биш.

Давхцах боломжгүй санг зохион байгуул

Холбогдсон бүх префикс, зарлагдсан бүх сайтын префиксээс гадна сан сонгоод, дараа нь түүнийг хоёр чиглэлд хүртээмжтэй болгох маршрутуудыг нэм. Төлөвлөгөөний ашиглагдаагүй хэсэгт 10.8.0.0/24 гэх мэт муж нь бодоход хялбар бөгөөд түүн рүү хүрэх шаардлагатай LAN нь VPN сервер рүү заасан статик маршрут авдаг. Хуваарилалт, зарлагдсан маршрут, зөвшөөрөгдсөн эх хаяг, галт ханын дүрмийг хамт өөрчил, учир нь тэдгээр нь дөрвөн тохиргоо биш нэг загварыг дүрсэлдэг.

Сервер дээрх Source NAT нь санг LAN-аас чиглүүлэх боломжтой хаягийн ард нууж чадах бөгөөд энэ нь хууль ёсны шилжилтийн хэрэгсэл юм. Энэ нь мөн эхийг дахин бичдэг тул LAN нь холболтыг тус тусын клиентэд хамааруулах, клиент тус бүрийн дүрэм хэрэгжүүлэх чадвараа алддаг.

Хүлээн авалтад бодит клиентийн үнэхээр олгогдсон хаяг болон LAN хостоос бодит аппликейшн хүсэлт ашиглаад, дараа нь хариулт нь утсаар биш төлөвлөсөн гарцаар явж байгааг батал.