BIND-ը VPN-ի վրա. պայմանական փոխանցո՞ւմ, թե stub գոտի
VPN-ի միջով մեկ մասնավոր գոտի լուծելու երեք եղանակ և երբ է յուրաքանչյուրը հարմար. forward, stub կամ secondary, գումարած աղբյուրի հասցեի ստուգումը, որը որոշում է։
Ձեր գրասենյակի resolver-ը պատասխանում է ամեն ինչի, բացի մեկ կորպորատիվ անվանատարածքից, և այն իմացող կորպորատիվ DNS սերվերը գտնվում է VPN-ի հետևում։ BIND-ը կարող է այդ մեկ գոտին հանձնել upstream-ին երեք տարբեր եղանակով, և դրանք տարբեր կերպ են ձախողվում։ Պայմանական փոխանցումը ամենափոքր պարտավորությունն է, stub գոտին պահում է պատվիրակման տվյալները, իսկ secondary-ն պահում է ամբողջական պատճեն։ Ընտրեք ըստ այն բանի, ինչ թույլ կտա upstream-ը և ինչ եք ուզում, որ ձեր resolver-ը պահի, ոչ ըստ այն բանի, թե որ հատվածն եք առաջինը գտել։
Երեք կարգավորում մեկ անվանատարածքի համար
| Type | What your resolver keeps | Upstream must | Fails when |
|---|---|---|---|
forward | a forwarder list | answer queries from your source address | upstream is down and forward only is set |
stub | the zone's NS records and addresses | answer NS queries for the zone | delegation data goes stale after an NS change |
secondary | a full copy of the zone | permit AXFR or IXFR from your source | transfer 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 հարցումը ձախողվի, stub գոտին չի կարող աշխատել, անկախ նրանից, թե ինչպես է վարվում forward գոտին։
Ստուգեք պատասխանը, ոչ թունելը
Հարցրեք գրասենյակի resolver-ի միջով մի անուն, որը երբեք չեք հարցրել, և նայեք պատասխանի authority բաժինը՝ տեսնելու, թե արդյոք այն եկել է կորպորատիվ գոտուց։ Քեշավորված պատասխանը ոչինչ չի ապացուցում ընթացիկ ուղու մասին, և upstream-ին ուղղակի հաջող հարցումը չի ապացուցում, որ ձեր resolver-ը ընտրել է այդ գոտին։ Կրկնեք նույն հարցումը TCP-ով՝ հաստատելու, որ ուղին դիմանում է կտրմանը։
Պահեք հաճախորդներին ուղղված գրասենյակի resolver-ին, և թողեք DNSSEC վավերացումը միացված։ Անկախ գաղտնագրված resolver-ով կարգավորված զննարկիչը ամբողջությամբ շրջանցում է այս կարգավորումը, և վավերացումն անջատելը, որպեսզի անսպասելի պատասխանը ճիշտ թվա, տեսանելի ձախողումը փոխանակում է անտեսանելիով։
Գրեք, թե երեք տեսակներից որն եք ընտրել և ինչու։ Հաջորդ մարդը, ով կտեսնի գոտու ձախողումը, այդ նախադասությանը ավելի շատ կարիք կունենա, քան կազմաձևի ֆայլին։