Маршрутлагдсан OpenVPN туннелээр нэрийн хайлт яагаад бүтэлгүйтдэг вэ

Хост ping-д хаягаар хариулдаг ч нэрээр хийсэн хайлт бүрт бүтэлгүйтдэг. Туннель асаалттай, маршрут байгаа тул VPN буруу тохируулсан гэсэн дүгнэлт гарна. Илүү ашигтай дүгнэлт нь тухайн хайлт хэзээ ч маршрутлагдах боломжгүй байсан: маршрутлагдсан туннель unicast IP зөөдөг бол асуулга нь нөгөө талд байхгүй сегментийг хайж байсан broadcast байв. Давхаргын зөрүү илэрсэн даруйд засварууд өөрсдөө өртгөөрөө эрэмбэлэгддэг.

Домог: нэрнүүд бүтэлгүйтдэг учраас туннель эвдэрсэн

Шинж тэмдэг нь итгэл үнэмшилтэй, учир нь нэрийн давхаргаас дээш бүхэн ажилладаг. Хаягууд маршрутлагдана, интерфейс асаалттай, хань нь ping-д хариулдаг. Бүтэлгүйтсэн нь цэгээс цэг рүү холбоогоор замгүй байсан илрүүлэх механизм бөгөөд энэ нь эвдэрсэн туннелээс өөр мэдэгдэл юм. Энэ хоёр мэдэгдлийг ялгах нь оношилгооны ихэнх хэсэг.

Үүнийг туннелийн гэмтэл гэж үзэх нь тус болохгүй профайлын өөрчлөлтөд хүргэдэг. Сонголт нэмэх, шифрлэлт солих эсвэл клиентийг дахин суулгах нь broadcast-ыг яг байсан газарт нь үлдээдэг.

Засварыг нэрлэхээс өмнө бүтэлгүйтсэн механизмыг нэрлээрэй. Broadcast ашигладаг хайлтад сегмент хэрэгтэй, харин шийдэгч ашигладаг хайлтад асуух хаяг хэрэгтэй.

TUN юу зөөдөг, юу зөөдөггүй

TUN төхөөрөмж нь IP интерфейс бөгөөд яг үүнээс болж маршрутлагддаг. OpenVPN клиентэд хаяг болон маршрутын багц өгдөг, үүнээс хойш клиент хань руу датаграм илгээдэг. Тэр загварт хост бүр кадр бүрийг сонсдог хуваалцсан холбоо үүсгэдэг зүйл байхгүй.

Илрүүлэх урсгал тэр загварт огт тохирохгүй. Windows-ийн хуучин нэрийн асуулга, SSDP зарлал, mDNS хүсэлтүүд нэг хүлээн авагч руу биш, сегмент дэх бүгдэд илгээгддэг. Маршрутлагдсан холбоонд илгээх «бүгд» байхгүй. Эдгээр механизм бүр хуваалцсан орчныг урьдчилж таамагладаг.

Тиймээс туннель эрүүл байхын зэрэгцээ илрүүлэлт бүрэн бүтэлгүйтэж болно. Хэн нэгэн VPN унасан гэж мэдээлэхэд баримтлах ёстой өгүүлбэр энэ юм.

Гүүрлэлт хил хязгаарыг арилгаснаар ажилладаг

TAP төхөөрөмж кадр зөөдөг бол гүүр түүнийг бодит LAN сегменттэй холбодог. Тэгвэл клиент тэр сегмент дээр хаягтай болж, түүний broadcast урсгалыг сонсдог. Гүүрлэлт нэрийн асуудлыг эмчилдэг мэт харагддаг шалтгаан энэ. Мөн клиентийг хаяглалтын хувьд тэр сегментээс хамааралтай болгодог.

Эмчилгээ нь маршрутын хилийг арилгах бөгөөд туннелийн доторх нэрийн шинэ чадвар биш. Сегментийн broadcast хийдэг бүхэн одоо холбоог мөн гатална.

Жижиг лабораторид энэ нь шударга солилцоо. Тархай ажиллах хүчинд ховор.

DNS болон WINS-ийг түлхэх нь илүү нарийн засвар

Клиентэд асуух тодорхой газар өг. dhcp-option DNS болон dhcp-option DOMAIN нь дотоод нэрийг бүсийг мэддэг сервер рүү чиглүүлдэг, NetBIOS-д найдаж байгаа Windows клиент мөн адил аргаар WINS сервер авч болно. Туннель маршрутлагдсан хэвээр, сегмент өөрийн газартаа үлдэнэ.

Хоёр нөхцөл үүнийг ажиллах эсэхийг шийднэ. Дурдсан сервер бүсийн төлөө хариулах ёстой, асуулга туннелээр зөвшөөрөгдөх ёстой.

Шийдэгчийг серверийн өөрийн бүрхүүлээс биш, клиентээс туршиж үзээрэй. Локалаар ажилладаг шийдэгч туннель юу зөөж байгаа талаар юу ч хэлэхгүй.

Аль давхарга бүтэлгүйтсэнийг олж мэдээрэй

Эхлээд хаяг руу ping хий, дараа нь нэрийг шийдэж, аль сервер хариулсныг унш. Бүсийг хост хийдэггүй серверийн сөрөг хариулт нь машинаас хэзээ ч гараагүй асуулгаас өөр харагдана. Шийдэгддэг ч холболтыг татгалздаг нэр бол огт өөр гурав дахь асуудал.

Multicast мөн адил хананы цаана. 224.0.0.251 төрлийн бүлэг анхдагчаар маршрутлагдсан туннелээр дамждаггүй бөгөөд multicast ойлгодог зам эсвэл LAN дахь ойлгогчгүйгээр бүлгийн маршрут хангалтгүй.