openfortivpn-ը անընդհատ վերագրում է DNS-ը․ գտե՛ք իսկական սեփականատիրոջը

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

Ստորև հաջորդականությունը հետևում է հաճախորդին դեպի դուրս․ ինչ փոխեց կապը, որ անջատիչն է լռեցնում որ գրողին, ով պետք է ստանձնի, և ինչպես հաստատել, որ արդյունքը դիմանում է վերակապակցմանը։ Յուրաքանչյուր փուլ թողնում է տարբեր հետք, և հենց հետքն է ասում ձեզ՝ արդյոք փոխանցումը իրոք տեղի ունեցավ։

Սկսե՛ք նրանից, թե ինչ իրոք փոխեց կապը

Միացե՛ք մեկ անգամ ձեր սովորական հրամանով և համեմատե՛ք լուծումը առաջ և հետո։ systemd-resolved-ով աշխատող Linux հոսթում resolvectl status տպում է DNS սերվերները և որոնման տիրույթները յուրաքանչյուր կապի համար, և սեփական սերվերներ կրող նոր tun կամ ppp կապը հաճախորդի կողմի թարմացման մատնահետքն է։ macOS-ում scutil --dns ցույց է տալիս լուծիչի կարգավորումը այն հերթականությամբ, որով հավելվածները դիմում են դրան։

Համեմատե՛ք դա այն ֆայլի հետ, որը սպասում էիք, որ կփոխվի։ Կապին կապված գրառումը յուրաքանչյուր կապի տեսքում և վերագրված /etc/resolv.conf-ը երկու տարբեր արդյունք են, և երկրորդը կարող է լինել խորհրդանշական հղում, որը լիովին կառավարում է մեկ այլ բան։ Գրանցե՛ք լուծիչի հասցեն, որոնման տիրույթները և միջերեսի անունը նույն պահին․ դրանցից ցանկացածի փոփոխությունը մատնանշում է այլ գրող։ Այդ հիմնագծի բացակայության դեպքում յուրաքանչյուր հետագա ուղղում ենթադրություն է այն մասին, թե երեք բաղադրիչներից որն է շարժվել։

Երկու անջատիչները և գրողը, որին լռեցնում է յուրաքանչյուրը

openfortivpn-ը փաստաթղթավորում է ընտրանքների հատված, որը անջատում է երկու գրողներին էլ, որոնց այն կարող է կառավարել, և յուրաքանչյուր անջատիչ ունի ամբողջությամբ գրված համարժեք, որը ձեռնարկը համարում է նույն կարգավորումը։

openfortivpn gw.example.com:443 --no-dns --pppd-no-peerdns
# written out in long form
openfortivpn gw.example.com:443 --set-dns=0 --pppd-use-peerdns=0

--no-dns-ը թույլ չի տալիս հաճախորդին կիրառել DNS սերվերները, որոնք սովորել է դարպասից, մինչդեռ --pppd-no-peerdns-ը թույլ չի տալիս pppd-ին գործընկերոջ DNS-ը հրել համակարգ։ upstream-ի ձեռնարկը զգուշացնում է, որ PPP-ի միջոցով DNS թարմացումները կարող են մրցել հաճախորդի սեփական DNS թարմացումների հետ, այդ իսկ պատճառով երկու անջատիչներն էլ պետք է լինեն հատվածում, փոխարենը՝ դրանցից որևէ մեկը բավարար համարելու։

Անջատիչներից ոչ մեկը փոխարինող լուծիչ չի նշում, և ոչ մեկը չի խանգարում ցանցի կառավարչին, DHCP հաճախորդին կամ առանձին VPN ինտեգրմանը հետո լուծում գրել։ Երկու գրողների լռեցումը դաշտը թողնում է բաց, ոչ թե պատկանող։ Եթե երրորդ բաղադրիչն արդեն կառավարում է DNS-ը, հատվածը ոչինչ չի փոխում, ինչ դուք կարող եք դիտել․ եթե ոչինչ չի կառավարում այն, դուք հենց նոր հեռացրիք մասնավոր անունների լուծման միակ աղբյուրը։ Դա վավեր դասավորություն է միայն այն դեպքում, երբ փոխարինող սեփականատերը նախ ընտրվել և ինքնուրույն փորձարկվել է։

Ընտրե՛ք սեփականատիրոջը, նախքան որևէ բան անջատելը

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

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

Ստուգե՛ք լուծումը յուրաքանչյուր կապի համար, ոչ թե ֆայլի

Մեկ /etc/resolv.conf-ը ցանկ չէ այն բանի, ինչ հավելվածներն իրոք օգտագործում են սահմանափակ կամ տիրույթային լուծում ունեցող հոսթում, ուստի կարդացե՛ք լուծիչի վիճակը այնպես, ինչպես հարթակը բացահայտում է այն։

resolvectl status
resolvectl query vpn.internal.example.com
resolvectl query example.com
ip route get 10.20.0.53

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

Վերակապակցվե՛ք և հաստատե՛ք անջատված վիճակը

Իջեցրե՛ք կապը և կրկնե՛ք երկու հարցումները։ Ինչ էլ որ ընտրված սեփականատերը տեղադրել է, այդ սեփականատերը պետք է հեռացնի կամ վերականգնի այն, ոչ թե թողնի ձեր լռեցրած հաճախորդը։ Թունելը վերապրող հնացած կապային գրառումը շարունակում է մասնավոր հարցումներ ուղարկել մի հասցե, որն այլևս հասանելի չէ։

Ապա նորից միացե՛ք և կարդացե՛ք նույն երեք արժեքները․ լուծիչի հասցե, որոնման տիրույթներ, միջերես։

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