DNS ձախողումներ HTTP վստահելի սերվերի շղթայում. ո՞ր թռիչքն է լուծում անունը:

Շղթայված forward proxy-ն ախտորոշելիս առանձնացրեք տեղական proxy-ին հասնելը, parent-ի լուծումը և կայքի լուծումը։

client → local forward proxy → HTTP parent → website

Սկսեք ձախողվող անունից, այլ ոչ թե ասեք, որ ամբողջ DNS-ը «proxy-ին» է պատկանում.

Անհրաժեշտ անունԹռիչք, որը պետք է հասնի դրան
Տեղական proxy-ի վերջնակետՀաճախորդ
HTTP parent-ի վերջնակետՏեղական forward proxy
Կայքի վերջնակետParent-ը, երբ բացում է վերջնական կապը

Այդ թռիչքները կարող են օգտագործել տարբեր լուծիչներ, երբ վերջնակետերը հոսթանուններ են։ HTTPS-ի դեպքում forward proxy-ն կարող է parent-ին փոխանցել CONNECT-ի նպատակակետ հոսթը և պորտը, որը հաստատում է վերջնական կապը։ Սկզբնական հաճախորդը պետք չէ նախ լուծի կայքը։ Սովորական HTTP փոխանցումը նույնպես նպատակակետի տեղեկությունը տանում է առաջ։

Սա խոստում չէ, որ յուրաքանչյուր անուն հարցնում է ճիշտ մեկ մեքենա։ ACL գնահատումը, քեշավորումը, քաղաքականությունը և իրականացման մանրամասները կարող են լրացուցիչ որոնումներ առաջացնել։

Ստուգեք պահուստային քաղաքականությունը, երբ parent-ը հասանելի չէ։ Եթե ուղիղ մուտքը թույլատրված է, տեղական proxy-ն կարող է դառնալ կայքին նայող թռիչքը՝ իր լուծիչի և աղբյուրի հասցեի որոշումներով։ Միայն parent կարգավորելը չի ապացուցում, որ յուրաքանչյուր հարցում օգտագործել է այն։

Ձախողման դեպքում նույնացրեք անունը և գործընթացը, որը փորձում է լուծել այն, նախքան hosts ֆայլը խմբագրելը։ Հաճախորդի կողմի խմբագրումը չի կարող ուղղել բոլոր հետագա որոշումները։ Վերջնական հանրային աղբյուրը պատկանում է այն թռիչքին, որը բացում է կայքի կապը. այդ աղբյուրին հետևելը նույնը չէ, ինչ չափելը, թե որտեղ է տեղի ունեցել DNS-ը։

Առնչվող հոդվածներ