VPN дээгүүр BIND: нөхцөлт дамжуулалт уу, stub бүс үү?

VPN-ээр нэг хувийн бүсийг шийдэх гурван арга, аль нь хэзээ тохирох нь: forward, stub эсвэл secondary, дээр нь шийдвэрийг тодорхойлох эх үүсвэрийн хаягийн шалгалт.

Танай оффисын resolver нэг корпорацийн нэрийн огторгуйг эс тооцвол бүгдэд хариулдаг бөгөөд түүнийг мэддэг корпорацийн DNS сервер VPN-ийн ард байдаг. BIND тэр нэг бүсийг upstream-д гурван өөр аргаар өгч болох бөгөөд тэд өөр өөрөөр бүтэлгүйтдэг. Нөхцөлт дамжуулалт нь хамгийн бага амлалт, stub бүс нь төлөөлөлийн өгөгдлийг хадгалдаг, secondary нь бүрэн хуулбарыг хадгалдаг. Эхлээд олсон хэсгээрээ бус, upstream юу зөвшөөрөх, resolver тань юу хадгалахыг хүсэж байгаагаар сонгоно уу.

Нэг нэрийн огторгуйд гурван зохион байгуулалт

TypeWhat your resolver keepsUpstream mustFails when
forwarda forwarder listanswer queries from your source addressupstream is down and forward only is set
stubthe zone's NS records and addressesanswer NS queries for the zonedelegation data goes stale after an NS change
secondarya full copy of the zonepermit AXFR or IXFR from your sourcetransfer is blocked by ACL or firewall

Нөхцөлт дамжуулалт: хамгийн бага амлалт

Оффисын resolver 192.168.10.53, корпорацийн сервер 10.40.0.53 хаяг дээр бөгөөд зөвшөөрөгдсөн туннелээр хүрч болно гэж үзье. Зарлал гурван мөр, хамгийн сонирхолтой нь forward only, учир нь зам биш, алдааны зан төлөвийг өөрчилдөг.

zone "corp.example" {
    type forward;
    forward only;
    forwarders { 10.40.0.53; };
};

forward only-тай үед хүрэх боломжгүй upstream энэ бүст итератив шийдэл рүү буцахын оронд SERVFAIL буцаана. Хувийн нэрийн огторгуйд ихэвчлэн үүнийг хүсдэг, учир нь буцалт нь хувийн нэрсийг нийтийн resolver руу илгээж, интернэтээс хэрэггүй хариу авчрах байсан. BIND-ийн лавлагаа хоёр бодлогыг төгс бичсэн, ялгаа нь хэсгээс харагдахаас илүү чухал. Ижил нэрэнд аль хэдийн байгаа бүсийг солихын оронд бүсийг одоо байгаа тохиргоонд нэгтгээрэй.

stub эсвэл secondary: төлөөлөл чухал үед

stub бүс нь корпорацийн серверээс бүсийн NS бичлэгүүдийг асууж, дараа нь эрх бүхий серверүүдээс шууд асуудаг. Upstream бүс том эсвэл хуваагдсан үед, бүгдийг нэг хаягт тогтоохын оронд resolver тань төлөөлөлийг дагахыг хүсвэл үүнийг сонгоно уу. Үнэ нь NS өгөгдөл шинэ байх, жагсаасан нэр сервер бүр resolver-ийн эх үүсвэрийн хаягаас хүрч болох зэргээс хамааралтай байх явдал юм.

zone "corp.example" {
    type stub;
    masters { 10.40.0.53; };
};

zone "corp.example" {
    type secondary;
    primaries { 10.40.0.53; };
    file "corp.example.db";
};

secondary нь локал өгөгдлөөс хариулж, upstream-ийн тасалдлыг даадаг, энэ нь дамжуулалтын хамаарлыг хүлээн авах шалтгаан юм. Энэ нь мөн resolver тань одоо өөрийн бус бүсийн хуулбарыг хадгалж байна гэсэн үг, тиймээс файлын зам, праймари дээрх дамжуулалтын ACL, шинэчлэх таймерууд бүгд таны үйл ажиллагааны гадаргуугийн хэсэг болно.

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

BIND өөрийн гарч буй асуултыг өөрөө үүсгэдэг, тиймээс асуулт нь зөөврийн компьютер 10.40.0.53-т хүрч чадах эсэх бус, resolver-ийн хост корпорацийн серверийн харах эх үүсвэрийн хаягаас хүрч чадах эсэх юм. Эхлээд цөмөөс, дараа нь серверээс асуугаарай, энэ дарааллаар.

ip route get 10.40.0.53
named-checkconf
rndc reload corp.example
dig @10.40.0.53 corp.example NS +norecurse
dig @192.168.10.53 portal.corp.example

Замаар UDP болон TCP-г зөвшөөрнө үү: тайрагдсан хариу TCP-г албаддаг, зөвхөн UDP зөвшөөрсөн бодлого пакет алдагдахтай төстэй үе үеийн алдаа үүсгэдэг. Корпорацийн талд resolver-ийн эх үүсвэрт хүлээн авах дүрэм болон түүн рүү буцах маршрут хоёулаа хэрэгтэй; тэр эх үүсвэр нь resolver-ийн чиглүүлсэн хаяг эсвэл тодорхой орчуулсан хаяг байж болох ба клиентийн пулын хаяг байх нь ховор. NS асуулт бүтэлгүйтвэл forward бүс хэрхэн аашлахаас үл хамааран stub бүс ажиллахгүй.

Туннелийг бус, хариуг шалгана уу

Хэзээ ч асуугаагүй нэрийг оффисын resolver-ээр асууж, хариуны authority хэсгийг хараад корпорацийн бүсээс ирсэн эсэхийг шалгана уу. Кэшлэсэн хариу одоогийн замын талаар юу ч батлахгүй, upstream-д шууд амжилттай хийсэн асуулт resolver тань тэр бүсийг сонгосныг батлахгүй. Ижил асуултыг TCP-ээр давтан хийж зам тайралтыг дааж байгааг батална уу.

Клиентүүдийг оффисын resolver рүү чиглүүлж байгаарай, DNSSEC шалгалтыг асаалттай байлгаарай. Бие даасан шифрлэгдсэн resolver-той тохируулсан хөтөч энэ зохион байгуулалтыг бүрмөсөн тойрч гардаг, санаанд оромгүй хариуг зөв харагдуулахын тулд шалгалтыг унтраах нь харагдах алдааг харагдахгүй алдаагаар солино.

Гурван төрлөөс алийг нь сонгосон, яагаад гэдгээ бичиж үлдээгээрэй. Бүс бүтэлгүйтэхийг дараагийн харах хүнд тохиргооны файлаас илүү тэр өгүүлбэр хэрэг болно.

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