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

1-р алхам: шийдвэрлэгч ба замыг нэрлэх

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

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

2-р алхам: бодлогыг үнэхээр оршдог газарт нь тавих

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

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

3-р алхам: замыг нарийнаар хэрэгжүүлэх

Одоо зөвшөөрөгдсөн замд сүлжээний зөвшөөрөл нэм: шийдвэрлэгчийн хаяг, протокол ба порт, гарах ёстой интерфейс. Бүх гадагш DNS-д зөвшөөрөл өгөхийн оронд дүрмийг тэр шийдвэрлэгчид хязгаарла. Доорх гурван зам бол орчин үеийн хэрэглэгчийн явж болох зам бөгөөд 53 портын дүрэм зөвхөн эхнийхийг хамрана.

PathPortWho controls it
Classic DNSUDP and TCP 53System resolver settings
DNS over TLSTCP 853Resolver or stub configuration
DNS over HTTPSTCP 443Browser or application policy

DoH ба DoT-г блоклох нь хууль ёсны; 53 портын дүрэм тэднийг аль хэдийн блоклосон гэж үзэх нь тийм биш. DoH ашигладаг хөтөч нэрсийг таны дүрэм хэзээ ч тодорхойлоогүй замаар шийдвэрлэдэг, өөрийн шийдвэрлэгчтэй програмууд ч мөн адил хийдэг. Зөвшөөрөх гэж буй зам бүр, татгалзах гэж буй зам бүрийг бич. Замыг нэрлээгүй дүрэм түүний талаар шийдвэр гаргаагүй.

4-р алхам: хувийн ба нийтийн нэрсийг дагах

Хуваасан DNS зөвхөн хувийн нэрийн орон зайг дотоод шийдвэрлэгч рүү санаатайгаар илгээдэг бол нийтийн нэрс өөр тийшээ явдаг, тиймээс загварт нэгээс олон шийдвэрлэгч байх нь алдагдал биш. Алдагдал гэдэг нь таны шийдвэрлэгч рүү явах ёстой байсан асуулга өөр газар очих, эсвэл хүрэх боломжгүй төлөвлөсөн зам хэрэглэгчийг чимээгүй буцаах явдал юм. Энэ хоёр тохиолдлыг л хайх хэрэгтэй. Төлөвлөсөн бодлогын дор нэг дотоод, нэг нийтийн нэрийг дагаж, аль шийдвэрлэгч аль нэгэнд хариулсныг тэмдэглэ.

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

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

5-р алхам: буцах замаа үлдээх

Гарцын DNS хандалтыг чангатгахаас өмнө нэр шийдвэрлэхээс хамааралгүй сэргээх аргыг батал. Эвдэрсэн шийдвэрлэгч засварын хэрэгсэл бүрт хүрэхэд хэцүү болгодог, өөрчлөлтийг буцаахад хэрэглэх хэрэгслүүд ч мөн адил. Шинэ бодлого батлагдах хүртэл локал консол эсвэл зурвасаас гадуур зам нээлттэй байлга. Бодлого дахин холбогдолтыг даван туулсны дараа л авч хая.

Дахин холбогдсон эсвэл хөтчийн бодлого шинэчлэгдсэний дараа үр дүнтэй төлөвийг дахин шалга, учир нь хоёулаа таны дүрмийг өөрчлөхгүйгээр шийдвэрлэгчийг сольж чадна. Шаардлага нь асуулгуудад танигдсан хүлээн авагч ба хамгаалагдсан зам, нэг дэлгэцийн зураг дээрх тайвшруулах шийдвэрлэгчийн шошго биш. RFC 8484 DNS over HTTPS тодорхойлолт нь таны портын дүрэм хардаггүй шифрлэсэн замын лавлагаа юм.

Холбоотой нийтлэлүүд