openfortivpn холбогдоход маршрут ба DNS-ийг хэн эзэмших ёстой вэ?

Ажиллаж буй openfortivpn сесс дээр дөрвөн үе шат бие биенийхээ дээр давхарлана. Клиент гарц дээр баталгаажуулалт хийж TLS холболт эхлүүлээд, дараа нь тэр холболтын дотор PPP ажиллуулж, дараа нь хаяг болон DNS мэдээлэл авч, эцэст нь хост маршрут болон resolver тохиргоог хэрэглэнэ. Дараагийн шат ажиллахгүй байхад ч үе шат бүр амьд байж болох тул дэмжлэгийн хэлэлцүүлэгт “холбогдсон” гэдэг үг ийм гулгамтгай байдаг.

Төөрөгдлийн ихэнхийг арилгах шийдвэр бол сүүлийн шатыг хэн эзэмших вэ гэдэг. Нэг бол VPN клиент хост өөрчлөлтийг өөрөө хэрэглэнэ, эсвэл өөр компонент хийнэ, хоёрыг хагас замд холих нь маршрут болон resolver файлууд өөр өөр сессийг дүрслэх шалтгаан болдог.

Нэг холболт мэт харагдах дөрвөн үе шат

Эхний шат бол хүлээн авалт. нэрлэсэн баталгаажуулалтын домэйн эсвэл нэг удаагийн кодоор, үргэлжлүүлэхэд шаардлагатай параметрүүдийг авна. Клиент гарцтай холбогдсон гэж хэвлэхэд энэ нь TLS тээвэр ажиллаж байгааг илтгэнэ. PPP хэлэлцээр хийсэн гэсэн үг биш, дотоод аппликейшн хүрэх боломжтой гэсэн үг ч мэдээж биш.

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

Гурав дахь шат бол тэр мэдээллийг хост дээр хэрэглэх бөгөөд энд эзэмшил чухал. Клиент маршрутуудыг нэмж resolver тохиргоог дахин бичиж болно, эсвэл ухарч хоёуланг нь тэр машины сүлжээг өөрөөр удирддаг зүйлд үлдээж болно. Төслийн README файл эдгээрийг нэг автомат зан төлөв бус, тусдаа хариуцлага гэж тодорхойлдог.

Маршрутжуулалтын хүснэгтийг хэн засварладаг

Анхдагчаар эзэмшигч нь клиент. Тэр физик интерфейсээр гарц руу маршрут, туннелийн хамтрагчид маршрут, сесс ашиглах зөвшөөрөлтэй сүлжээнүүдэд маршрутууд нэмж, дараа нь процесс гарахад тэдгээрийг устгадаг. Энэ анхдагч нь нэг сүлжээний менежертэй, өөр VPN програм хангамжгүй зөөврийн компьютер дээр тохиромжтой.

Өөр зүйл маршрутжуулалтыг үнэхээр эзэмшиж байгаа үед л шилжүүлэлтийг сонго. Сүлжээний менежерийн интеграци, контейнерийн сүлжээний нэрийн орон зай, эсвэл бүх сайтын маршрутжуулалтын агент ижил префиксүүдийг хэрхэн суулгах, цэвэрлэхийг мэддэг байж болно. no-routes сонголтыг өгөх нь тэгвэл хоёр бичигчийг нэг хүснэгтийн төлөө тэмцэхээс сэргийлнэ, энэ нь цэвэр алдаа биш, нэг дэд сүлжээ үе үе алга болох хэлбэрээр илэрдэг уралдаан юм.

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

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

DNS ба resolver файлыг хэн эзэмшдэг

DNS бол ижил шийдвэр, илүү хурц ирмэгтэй. Клиент гарц эсвэл PPP хамтрагчийн мэдээлдэг DNS серверүүдийг хүлээн авч, тэдгээрийг хост resolver тохиргоонд бичиж болно. Энгийн машин дээр энэ нь яг таны хүсч байгаа зүйл, учир нь дотоод нэрс туннель ажиллаж байх үед л шийдэгддэг.

Орчин үеийн Linux хост дээр resolver-ийг локал stub удирдаж болох бөгөөд resolver файлыг тэр stub-ийн нурууны цаана дахин бичих нь зөв харагдах боловч тууштай бус ажилладаг тохиргоог үүсгэдэг. Хост аль хэдийн resolver менежер ажиллуулж байгаа бол DNS-ийг түүнд эзэмшүүлж, туннелийн серверүүдийг түүний дэмжигдсэн интерфейсээр дамжуулан өг. Клиентийн no-dns сонголт тэнд зөв сонголт бөгөөд тойрч гарах арга биш.

Хуваасан DNS нь файлыг хэн бичдэгээс тусдаа асуулт. Асуулга бүрийг туннелээр илгээх нь энгийн бөгөөд удаан; зөвхөн дотоод бүсийг түүгээр илгээхэд ихэнх энгийн клиентүүд санал болгодоггүй домэйн тус бүрийн тохиргоо шаардлагатай. Клиентийн resolver өөрчлөлтийг идэвхжүүлэхийн өмнө хостод ямар зан төлөв хэрэгтэйг шийд. Энд буруу сонголт хийвэл туннель өөрөө зүгээр байсан ч нэр шийдвэрлэх тасалдал мэт харагдана.

Эрх, бэлэн байдал ба шилжүүлэлт

Туннелийн төхөөрөмж үүсгэх, хост маршрут эсвэл resolver төлөвийг засварлах нь дээшлүүлсэн сүлжээний эрх шаарддаг. Нийтлэг алдаа нь тиймээс бүх зүйл root-оор ажиллах ёстой гэж дүгнэх, үүнд хөтөч эсвэл туннель ашигладаг аппликейшн орно. Эрхтэй хэсгийг жижиг байлга: клиент болон түүний тохиргооны файл администраторын эзэмшилд, харин хэрэглэгчийн аппликейшнүүд ердийн бүртгэлээ хадгална.

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

Гэрээг дөрвөн ажиглалтаар шалга: гарцын шат дуусна, PPP хаяг олгоно, зорьсон маршрут байна, дотоод хост руу хүсэлт амжилттай болно. Дараа нь клиентийг зогсоож, тэдгээр бүр устгагдсан эсвэл сэргээгдсэн эсэхийг батал. Хэрэв туннель хаагдсаны дараа хост дотоод нэрсийг шийдсээр байвал эсвэл маршрут барьсаар байвал эзэмшлийн шилжүүлэлт бүрэн бус байна.