Ինչո՞ւ է երթուղիչի սեփական DNS-ը շրջանցում VPN թունելը

Հաճախորդների հարցումները հետևում են թունելին, մինչդեռ երթուղիչի սեփական հարցումները դուրս են գալիս WAN-ով, և հրակայուն պատի այն կանոնը, որը կառավարում է մեկին, ոչ մի ազդեցություն չունի մյուսի վրա։ Պատճառը սխալ չէ. փոխանցված հարցումը և երթուղիչի ինքնուրույն ստեղծած հարցումը երկու առանձին հոսքեր են, և յուրաքանչյուրը համադրվում է կարգավորումների տարբեր մասի հետ։ Միայն հաճախորդի կեսը գրանցելը վստահ պատասխան է տալիս մի ուղու մասին, որ երկրորդ կեսը երբեք չի օգտագործում։ Ուղղումը երթուղիչի լուծիչը դիտավորյալ ուղղելն է, ապա երկու ուղիներն առանձին ստուգելը։

Որ հոսքին է իրականում պատկանում փաթեթների գրանցումը

Մեկ հարցումը ներառում է երկու փոխանակում։ LAN հաճախորդը հարցում է ուղարկում երթուղիչի լուծիչին, և այն հասնում է որպես փոխանցված երթևեկություն LAN միջերեսի վրա, ուստի փոխանցված փաթեթների համար գրված քաղաքականության երթուղին կամ NAT կանոնը կարող է համապատասխանել դրան։ Այնուհետև երթուղիչը պատասխանում է քեշից կամ, բաց թողնելու դեպքում, բացում է իր սեփական հարցումը դեպի վերևի սերվեր։

Այդ երկրորդ հարցումն ունի երթուղիչն ինքը որպես աղբյուր և որպես սեփական նպատակակետ, և հարթակը նրա ուղին ընտրում է կարգավորումների մեկ այլ բլոկից։ Երկու փոխանակումներն էլ կրում են նույն անունը, և ոչ մեկը մյուսի պատճենը չէ։ Այսպիսով LAN կողմում վերցված գրանցումը ապացուցում է, թե ուր գնաց հաճախորդի փաթեթը, և ոչինչ չի ասում ելքային փաթեթի մասին։

Գործնական ստուգումը երկու կողմերին միաժամանակ դիտարկելն է։ Երթուղիչի վրա թվարկեք լուծիչի սոկետը, հարցրեք այն տեղական և գրանցեք WAN միջերեսը:

sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53

Եթե սոկետների ցանկը ցույց է տալիս loopback կամ LAN հասցեին կապված լսող, ապա երթուղիչը պատասխանում է տեղական՝ այլ հոսթ փոխանցելու փոխարեն։ Այդ դեպքում գրանցումը ցույց է տալիս՝ առաջացած դեպի վեր հարցումը դուրս է գալիս թունելի միջերեսով, թե WAN-ով, և դա այն պատասխանն է, որ քաղաքականության երթուղու կանոնը երբեք չէր տա։

Ինչու քաղաքականության երթուղին երբեք չի տեսնում երկրորդ հարցումը

Հրակայուն պատի կանոնները գրվում են միջերեսի, աղբյուրի, նպատակակետի և պորտի համար, և դրանք գնահատվում են սարքի միջով անցնող փաթեթների համար։ Երթուղիչի ստեղծած հարցումը ոչ մի բանով չի անցնում, որովհետև տեղական գործընթացն այն ուղղակիորեն հանձնում է երթուղային աղյուսակին։ Քաղաքականության երթուղում և NAT հետևաբար վերաբերում են միայն փոխանցված ուղուն, և հենց դրա համար կանոնների հավաքածուն կարող է ամբողջական թվալ և միևնույնն է երթուղիչի DNS-ը թողնել թունելից դուրս։

Այս տարբերությունը վերապրում է ամեն ծրագրաշարի վերաշարադրում, որովհետև այն բխում է փաթեթի ուղուց, ոչ թե գործառույթից։ Այն ամենը, ինչ սարքը ստեղծում է իր համար՝ լինեն լուծիչի հարցումներ, ժամանակի համաժամեցում, թարմացումների ստուգումներ կամ փաթեթների հայելիների հասանելիություն, տեղական ծագում ունի և ընկնում է նույն կույր կետը։ Դրա համար էլ նոթբուքից արված թեստը ոչինչ չի ապացուցում երթուղիչի մասին։

Որտեղ է pfSense լուծիչը որոշում իր դեպի վեր ուղին

pfSense-ը տեսանելի է դարձնում այդ բաժանումը։ Հաճախորդի երթևեկությունը կարելի է քաղաքականության երթուղով անցկացնել VPN դարպասով, մինչդեռ հրակայուն պատի սեփական երթևեկությունը հետևում է լուծիչի ելքային կարգավորմանը, այլ ոչ LAN կանոններին։ Վեբ միջերեսում այդ կարգավորումը գտնվում է Services > DNS Resolver > Outgoing Network Interfaces-ի տակ, և դրա արժեքը միջերեսների ցանկն է, որոնք լուծիչը կարող է օգտագործել դեպի վեր հարցումների համար։

Այնտեղ թունելի միջերեսը նշելը, և միայն այդ միջերեսը, այն է, ինչ ստիպում է երթուղիչի սեփական հարցումներին հետևել թունելին։ Կանխադրված թողնելու դեպքում լուծիչը ելք է ընտրում երթուղային աղյուսակից, որը երկու WAN կամ VPN ունեցող հոսթում հաճախ WAN-ն է։

Այլ ծրագրաշարեր նույն որոշումը ցուցադրում են այլ պիտակի տակ՝ աղբյուրի հասցեին կապված դեպի վեր սերվերների ցանկ, միայն փոխանցման ռեժիմ կամ փաստաթղթավորված երթուղային քաղաքականություն։ Փնտրելի կարգավորումը միշտ այն է, որ տեղական ստեղծված հարցումների համար ընտրում է ելք կամ աղբյուր։ Լուծիչի կարգավորման տեղեկագիրքը փաստաթղթավորում է այդ տարբերակը pfSense-ի համար և արժե կարդալ նախքան փոփոխությունը։

Ընտրեք ձախողման վարքը կարգավորումից առաջ

Երբ թունելն ընկնում է, երկու վարք պաշտպանելի է՝ դադարեցնել դեպի վեր հարցումները, որպեսզի ոչինչ չարտահոսի, կամ վերադառնալ հաստատված լուծիչի հայտնի ուղու վրա։ Երկուսն էլ քաղաքականություն են, և ոչ մեկը այն չէ, ինչ ստանում եք կանխադրված։ Որոշեք, թե ցանցին որն է պետք, նախքան միջերեսների ցանկին դիպչելը։

Ձախողման դեպքում փակվելը ավելի հեշտ է պաշտպանել, բայց այն թունելի ընդհատումը դարձնում է անվանումների լուծման ընդհատում երթուղիչի հետևում գտնվող յուրաքանչյուր սարքի համար։ Վերադարձը գրասենյակը պահում է օգտագործելի, բայց թունելից դուրս դեպի վեր փոխանակման գնով, որը պետք է ընդունելի լինի դիտավորությամբ, ոչ պատահաբար։ Գրեք ընտրությունը, որովհետև հաջորդ մարդը, ով VPN-ից դուրս լուծիչի հասցե կտեսնի, դա կկարդա որպես արտահոսք, եթե գրառումն այլ բան չասի։ Հենց այդ գրառումն է բաժանում փաստաթղթավորված վերադարձը հաջորդ եռամսյակի վերանայման մեջ չբացատրված հայտնաբերումից։

Երկու դեպք բարդացնում են որոշումը։ Մասնավոր անուններին կարող է անհրաժեշտ լինել ներքին լուծիչ, որին թունելը հասնում է, և սեփական գաղտնագրված DNS ունեցող զննարկիչը կամ հավելվածը կարող է ամբողջությամբ շրջանցել երթուղիչը, ուստի ձեր կարգավորած լուծիչը միշտ չէ, որ այն է, ինչ օգտագործում է տվյալ հավելվածը։

Ստուգեք երկու ուղիներն էլ և արդյունքները պահեք առանձին

Զննարկիչում արված DNS թեստը պատասխանում է նեղ հարցի՝ որ լուծիչներն է օգտագործել այդ զննարկիչը այդ թեստի պայմաններում։ Այն չի հաշվառում ցանցի սարքերը և չի կարող տեսնել երթուղիչի ստեղծած հարցումն իր համար։ Վերաբերվեք դրա արդյունքին որպես մեկ տվյալի կետի, ոչ որպես աուդիտի։

LAN հաճախորդից երթուղիչից խնդրեք հանրային անուն, ապա մասնավոր անուն, որին պետք է պատասխանի միայն ձեր ներքին գոտին։ Միայն երկրորդ հարցման ձախողումը մատնանշում է անունների փոխանցումը, ոչ թունելը:

dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lan

Այնուհետև իջեցրեք թունելը և կրկնեք երկու հարցումները։ Մերժված պատասխանները նշանակում են, որ լուծիչը փակվում է ձախողման դեպքում. հաջող պատասխանը մատնանշում է պահուստային լուծիչ և նրա օգտագործած ուղին։ Համեմատեք դա ձեր գրած գրառման և նույն րոպեին WAN միջերեսում արված գրանցման հետ։

Գրանցամատյանում դիտարկումները պահեք առանձին՝ հաճախորդի և երթուղիչի փոխանակումը, երթուղիչի և վերևի սերվերի փոխանակումը, և այն կարգավորումը, որը որոշեց երկրորդը։ Հետագա երթուղային փոփոխությունը կմիացնի այդ երկրորդ փոխանակումը առանց նախազգուշացման։ Պատասխանը, որը գալիս է VPN վերջնակետից բացի այլ տեղից, ինքնին արտահոսք չէ. այն արտահոսք է դառնում միայն այն ժամանակ, երբ կարգավորումը պատահաբար ընտրել է այդ ուղին։