openfortivpn DNS-ийг байнга дарж бичиж байна уу? Жинхэнэ эзэмшигчийг олоорой

Холболт дээшилсэн мөчөөс эхлэн дагаарай: клиент баталгаажуулж, pppd хэлэлцээ хийж, дараа нь ямар нэг зүйл DNS тохиргоог үйлдлийн системд бичдэг. Хэрэв VPN таны шийдэгчийг өөрчилснийг л мэдэж байвал, эдгээр үе шатуудын аль нь үүнийг хийснийг одоо хүртэл мэдэхгүй байна. Тэдний хоёр нь чадна, бөгөөд баримтжуулсан pppd интеграцийг ашигладаг клиент дээр тэд нэг оролцогч мэт харагдахаар ойр ажилладаг. Бичигчийг нэрлэх нь эхний алхам; түүний орлуулагчийг сонгох нь хоёр дахь бөгөөд энэ нь өөрийн гэсэн бүтэлгүйтлийн горимтой тусдаа шийдвэр юм.

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

Холболт үнэхээр юуг өөрчилснөөс эхэл

Ердийн командаараа нэг удаа холбогдож, шийдлийг өмнө болон дараа нь харьцуул. systemd-resolved ажиллуулдаг Linux хост дээр resolvectl status холбоос бүрийн DNS сервер болон хайлтын домейнуудыг хэвлэдэг бөгөөд өөрийн серверүүдийг зөөдөг шинэ tun эсвэл ppp холбоос нь клиент талын шинэчлэлийн хурууны хээ юм. macOS дээр scutil --dns шийдэгчийн тохиргоог програмууд түүнд хандах дарааллаар харуулдаг.

Үүнийг өөрчлөгдөнө гэж хүлээж байсан файлтай харьцуул. Холбоос бүрийн харагдацад байгаа холболтод холбогдсон бичлэг болон дахин бичигдсэн /etc/resolv.conf хоёр өөр үр дүн бөгөөд хоёр дахь нь огт өөр зүйл удирддаг симбол холбоос байж болно. Шийдэгчийн хаяг, хайлтын домейн, интерфэйсийн нэрийг нэг мөчид бич, тэдгээрийн аль нэг нь өөрчлөгдвөл өөр бичигч рүү заана. Тэр суурь шугамгүйгээр дараагийн засвар бүр гурван бүрэлдэхүүний алий нь хөдөлсөн тухай таамаг л юм.

Хоёр унтраалга ба тус бүрийн дардаг бичигч

openfortivpn өөрийн хянаж чадах хоёр бичигчийг бүгдийг унтраадаг сонголтын хэсгийг баримтжуулдаг бөгөөд унтраалга бүр гарын авлага ижил тохиргоо гэж үздэг бүрэн бичсэн эквиваленттай.

openfortivpn gw.example.com:443 --no-dns --pppd-no-peerdns
# written out in long form
openfortivpn gw.example.com:443 --set-dns=0 --pppd-use-peerdns=0

--no-dns клиентийг гарцаас сурсан DNS серверүүдийг хэрэглэхээс сэргийлдэг бол --pppd-no-peerdns pppd-г хамтрагчийн DNS-ийг системд түлхэхээс сэргийлдэг. upstream гарын авлага PPP-ээр хийгдэх DNS шинэчлэлт клиентийн өөрийн DNS шинэчлэлттэй өрсөлдөж болзошгүйг анхааруулдаг, тиймээс аль нэгийг хангалттай гэж үзэхийн оронд хоёр унтраалга хоёулаа хэсэгт байх ёстой.

Аль ч унтраалга орлуулах шийдэгчийг нэрлэхгүй бөгөөд сүлжээний менежер, DHCP клиент эсвэл тусдаа VPN интеграцийг дараа нь шийдэл бичихээс сэргийлдэггүй. Хоёр бичигчийг дарснаар талбарыг эзэмшсэн биш, нээлттэй үлдээдэг. Гурав дахь бүрэлдэхүүн DNS-ийг аль хэдийн удирдаж байгаа бол хэсэг нь таны ажиглаж болох юуг ч өөрчлөхгүй; хэрэв юу ч үүнийг удирдахгүй бол та хувийн нэрсийн шийдлийн цорын ганц эх сурвалжийг дөнгөж салгалаа. Энэ нь орлуулах эзэмшигчийг эхлээд сонгож, тусдаа туршсан тохиолдолд л хүчинтэй зохион байгуулалт юм.

Ямар нэг зүйлийг идэвхгүй болгохын өмнө эзэмшигчийг сонго

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

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

Шийдлийг файл бүрээр биш, холбоос бүрээр шалга

Хязгаарлагдмал эсвэл домэйн тус бүрийн шийдэлтэй хост дээр програмууд үнэхээр юу ашигладгийн жагсаалт нь ганц /etc/resolv.conf биш, тиймээс шийдэгчийн төлөвийг платформ ил гаргадаг байдлаар унш.

resolvectl status
resolvectl query vpn.internal.example.com
resolvectl query example.com
ip route get 10.20.0.53

Холболт дээшилсний дараа нэг хувийн нэр, нэг нийтийн нэрийг асууж, аль холбоос аль нэгэнд хариулсныг тэмдэглэ. VPN холбоос домэйн тус бүрийн хайлтын жагсаалт зөөдөг газарт хувийн нэр зөв шийдэгдэж болох бөгөөд нийтийн нэр нь орон нутгийн шийдэгч рүү явсаар байна, тэр хуваагдал нь гэмтэл биш, ажиллаж буй загвар юм. Хувийн асуулт бүтэлгүйтвэл DNS-д дахин хүрэхийн өмнө шийдэгч рүү хүрэх замыг шалга; амжилттай болсон ч програм бүтэлгүйтсээр байвал програм өөрийн кэшлэсэн эсвэл тусдаа тохируулсан шийдэгчийг уншиж байж магадгүй.

Дахин холбогдож, салсан төлөвийг батал

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

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

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