OpenVPN-ийг TAP-аас TUN руу шилжүүлэх: ажилладаг шилжилтийн дараалал

dev tap-ыг dev tun-оор солих нь туннель юу дамжуулж байгааг өөрчилнө, зөвхөн нэрийг нь биш. TAP интерфэйс Ethernet хүрээг гүүр руу дамжуулдаг тул клиентүүд оффисын свитчэд залгасан мэт ажиллана. TUN интерфэйс IP пакет дамжуулдаг тул клиентүүдэд маршрут, нөгөө талд буцах зам хэрэгтэй. Клиентүүд, хаягийн төлөвлөгөө, LAN-ын буцах маршрут бүгд тэр өөрчлөлтэй хамт шилжих ёстой.

Шилжилт нь туннельтэй холбогдсон сүлжээний дахин төлөвлөлт бөгөөд доорх дараалал үүнийг буцаах боломжтой байлгана.

Ethernet-ээс үнэхээр хамааралтай зүйлсийг тоол

Хост биш, аппликейшнүүдийг жагсаа. Тус бүр нь маршрутлагдсан TCP эсвэл UDP үйлчилгээ, броудкаст илрүүлэлт, оффисын LAN-аас DHCP, IP бус Ethernet протокол, эсвэл хоёр тал нэг дэд сүлжээнд байна гэсэн таамаглалын алиг ашигладаг болохыг тодорхойл. Энгийн IP хандалт маршрутлагдсан загварт ажиллана. Түүхий Ethernet хүрээ шаарддаг протокол ажиллахгүй бөгөөд ямар ч маршрутлалт үүнийг засахгүй. Илрүүлэлтээс хамааралтай аппликейшнүүдэд шилжилтийн өмнө шийдсэн орлуулах механизм хэрэгтэй, шилжилтийн үеэр биш.

Тэр жагсаалт нь мөн хүлээн авалтын жагсаалт юм. Шилжүүлж чадахгүй оролт бүр баримтжуулсан үл хамаарах зүйл эсвэл зөвхөн тэр ажлын ачаалалд зориулж жижиг TAP сегментийг амьд үлдээх шалтгаан болно.

Хаяг ба буцах маршрутын төлөвлөгөө гарга

LAN, хуучин гүүрийн муж, клиентийн аль хэдийн хүрч байгаа сүлжээтэй давхцахгүй клиентийн угтварыг сонго. Дэд сүлжээний топологитой серверт dev tun, topology subnet, server 10.78.0.0 255.255.255.0 зэрэг хэсэг хэрэгтэй, гэхдээ энэ нь зөвхөн хэсэг бөгөөд ажилладаг профайл биш. Түүнийг тойрсон зөвшөөрөгдсөн TLS, таних, тээвэр, хандалтын бодлогыг хадгалж, чөлөөтэй гэдгийг нь шалгасан угтвар ашигла.

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

Тусдаа сонсогч дээр туршилт хий

Шинэ үйлчилгээг ажиллаж байгаа цорын ганц орох цэгийг солихын оронд хуучин үйлчилгээний хажуугаар өөрийн порт, өөрийн хаягийн мужид байрлуул. Шилжилтийн улмаас хэн ч CA-г дахин барихгүйн тул туршилтын профайлуудыг одоо байгаа бүртгэлийн процессоор олго. Зөвхөн туршилтын зам идэвхтэй үед нэг төлөөлөх клиентийг холбож, дараа нь олгогдсон хаяг, хувийн DNS, жагсаалтын аппликейшнүүд, хаалттай үлдэх ёстой замуудыг харьцуул.

Дахин холбогдолт ба буцах урсгалын тестийг оруул. Дууссан гар барилт нь нөгөө тал хариу өгч чадах эсэхийг юу ч хэлэхгүй.

Клиентүүдийг буцаалттай бүлэгээр шилжүүл

Алдаа нь тасалдал бус дэмжлэгийн ажил болох хэмжээгээр жижиг бүлэгээр шилжүүл. Бүлэг бүрийн бодит ажлын урсгал давах хүртэл хуучин үйлчилгээг ажиллуулж, баримтжуулж бай, буцаалтыг дахин бүтээх биш, өмнөх профайл руу буцах шилжилт гэж бич. Бүлэг бүр шилжих бүрт хаягт суурилсан галт ханы дүрэм, хяналт, серверээс эхэлсэн аливаа хандалтыг шинэ угтварт тохируул.

Хуучин зам харьцуулалтад бэлэн байхад хэн ч дурдаагүй аппликейшнийг илрүүлэх газар ч бүлэгүүд өгдөг.

Хүлээн авалтын дараа л гүүрийг хаа

TAP төхөөрөмжийг устгах нь эхний биш, сүүлийн алхам юм. Ямар нэг зүйлийг устгахаас өмнө гүүр серверийн удирдлагын хаяг, хяналтын зам эсвэл хамааралгүй ажлын ачаалалыг дамжуулж байгаа эсэхийг шалга. Эхлэх хараат байдал, гүүрийн гишүүнчлэл, DHCP нөөцийг эзэмшиг дамжуулан, яг тэр дараалаэр, юу хасагдсаныг тэмдэглэн хаа.

Маршрутлагдсан хандалтын загвар жагсаалтад ажиллах үед шилжилт дуусна, ip link-ийн гаралтаас TAP интерфэйс алга болох үед биш.