Ինչու է DNS պատասխանը ձախողվում անվիճակ VPN եզրի ֆայրվոլում
VPN հոսթի DNS հարցմանը եկող պատասխանը կրում է աղբյուր պորտ 53, ոչ թե նպատակակետ 53։ Սահմանափակեք կանոնը իրական լուծիչով և ուղու եզրով։
Թունելը բաց է, հաճախորդները հասնում են VPN հոսթին, իսկ հոսթը ոչինչ չի կարողանում լուծել։ Նրա սեփական ելքային հարցումները մաքուր թողնում են ինտերֆեյսը, ուրեմն խափանումը վերադարձի ճանապարհին է՝ վերին եզրում, որը զտում է մուտքային երթևեկությունը՝ չհիշելով, թե ինչ հենց նոր ուղարկեց հոսթը։ Թունելի պորտը թույլատրելը բոլորովին չի նկարագրում այդ փոխանակումը։ DNS հարցման պատասխանը առանձին հոսք է, և եթե եզրը անվիճակ է, ոչինչ թույլտվություն չի տվել նրան վերադառնալ։
Երկու փոխանակումները նույն փոխանակումը չեն
Գրեք բազմակները և սխալը դառնում է ակնհայտ։ Հարցման նպատակակետ պորտը դառնում է պատասխանի աղբյուր պորտ, ինչը հակառակն է այն բանի, ինչ պատկերացնում է մեծամասնությունը՝ 53 պորտի համար մուտքային կանոն ավելացնելիս։
query: 203.0.113.10:53018 -> 198.51.100.53:53
reply: 198.51.100.53:53 -> 203.0.113.10:53018Մուտքային կանոնը, որը պահանջում է նպատակակետ պորտ 53, նկարագրում է հոսթի վրա աշխատող DNS լսողին ուղղված երթևեկություն, ինչը բոլորովին այլ ծառայություն է։ Այդ հասցեները փաստաթղթային օրինակներ են, և աղբյուր պորտը հաճախորդն ընտրում է յուրաքանչյուր հարցման համար, ուստի սա այն արժեքը չէ, որը կարելի է պատճենել կանոնի մեջ և ակնկալել, որ այն կշարունակի աշխատել։
Անվիճակ եզր ընդդեմ վիճակով հոսթի ֆայրվոլի
Անվիճակ եզրային զտիչը գնահատում է յուրաքանչյուր մուտքային փաթեթ իր կանոնների ցանկի դեմ՝ առանց հետևում կապերի աղյուսակի։ Հաջողությամբ դուրս եկած ելքային հարցումը թույլտվություն չի ստեղծում իր մուտքային պատասխանի համար, որովհետև սարքը գրառում չունի, որ հարցում երբևէ եղել է։ Վիճակով հոսթի ֆայրվոլը հակառակն է՝ նրա կապերի հետևումը ճանաչում է թույլատրված փոխանակման վերադարձ երթևեկությունը և բաց թողնում այն առանց պատասխանի կանոնի։ Երկու սահմաններն էլ գոյություն ունեն բնորոշ ուղու վրա, և երկուսն էլ պետք է թույլատրեն նախատեսված փաթեթը։
Համեմատությունը կարևոր է, որովհետև երկու սարքերը տարբեր կերպ են ձախողվում։ Պատասխանը մերժող վիճակով ֆայրվոլը գրանցում է մերժում; անվիճակ եզրը մերժում է լուռ, դրա համար էլ հոսթը պարզապես ժամանակավորվում է։
Թույլտվությունը կառուցեք արձանագրության շուրջ, ոչ թե պորտի համարի
Սահմանափակեք կանոնը լուծիչի իրական հասցեներով, նպատակակետ հոսթով և արտադրանքի աջակցած ընդունող պորտի քաղաքականությամբ։ Հիշեք նաև DNS-ի TCP ուղին, որովհետև մեծ պատասխանը կամ կրճատման պատճառով հետընթացը փոխանակումը տեղափոխում է TCP, և միայն UDP-ի կանոնը չի ծածկի այն։ Եթե եզրը աջակցում է վիճակով ստուգում որոշված հոսքի համար, նախընտրեք այն ձեռքով գրված պատասխանի կանոնից, որովհետև վիճակով ուղին ինքնաշխատ հետևում է հաճախորդի ընտրած պորտերին։
Ապա հաստատեք, թե ուղու որ արտադրանքն է իսկապես զտում երթևեկությունը։ Փաստաթղթավորված IPv4 եզրի շրջանակը IPv6 քաղաքականություն չի հաստատում, և մատակարարի ներքին երթևեկությունը գուցե երբեք չանցնի այդ նույն զտիչով։
Ինչու ցանկացած աղբյուր պորտ 53 թույլատրելը լուծում չէ
Կանոնը, որն ընդունում է այն ամենը, ինչ պնդում է աղբյուր պորտ 53, այն կանոնն է, որն ընդունում է այն, ինչ ուղարկողը գրում է վերնագրի դաշտում։ Պորտի համարը չի վավերացնում ուղարկողին և չի ապացուցում, որ բեռնվածքը վավեր պատասխան է, ուստի կանոնը լայնացնում է հոսթի խոցելիությունը՝ չդարձնելով լուծումը ավելի հուսալի։ Պահեք աղբյուրի սահմանափակումները և հաճախորդի սեփական պատասխանի ստուգումները, ներառյալ աղբյուր պորտի պատահականացումը, փոխանակ դրանք անջատելու՝ մուտքի ցանկը պարզեցնելու համար։
Եթե լուծիչը ձեր վերահսկած ծառայությունն է, բավական է սահմանափակվել նրա հասցեներով։ Եթե այն հանրային լուծիչ է, սահմանափակվեք ձեր հաստատած հասցեներով և նշեք դրանք կանոնի մեկնաբանության մեջ։
Ստուգեք ճիշտ սահմանում, ճիշտ ուղղությամբ
Գրանցեք հոսթում և եզրում նույն հարցման համար, և համեմատեք բազմակները, ոչ թե փաթեթների հաշվարկը։ Երկու կողմում տեսանելի հարցումը՝ առանց հոսթի կողմում տեսանելի պատասխանի, մատնանշում է մուտքային զտիչը; միայն հոսթի կողմում տեսանելի հարցումը մատնանշում է երթուղավորումը կամ ինքը լուծիչը։ Կրկնեք TCP հարցումով, եթե ունեք միայն UDP թույլտվություն, որովհետև հենց այդ բացն է, որ առաջին փորձարկումը չի տեսնում։
Սա ուղղելը ավարտում է DNS փոխանակում, որն իսկապես անհրաժեշտ է հոսթին։ Այն հոսթին հանրային լուծիչ չի դարձնում, չի թույլատրում փոխանցված VPN հոսքերը և չի ապացուցում, որ DNS-ն էր ինչ-որ անկապ թունելի խնդրի պատճառը։