AWS Client VPN վերջնակետի DNS. ինչու է լուծված IP-ի ամրագրումը ձախողվում
Փոխարինեք AWS Client VPN վերջնակետի անունը ձեր լուծած հասցեով, և թունելը հետո կդադարի աշխատել։ Պահեք արտահանված անունը և նրա պատահական նախածանցը։
Անցյալ շաբաթ dig +short-ը ձեզ մեկ հասցե տվեց ձեր AWS Client VPN պրոֆիլի վերջնակետի անվան համար, և թունելը միացավ։ Այս շաբաթ նույն պրոֆիլը ձեր նոթբուքում մնում է 'Connecting' վիճակում, մինչ գործընկերոջ չդիպված պատճենը դեռ աշխատում է։ Ոչինչ չի արգելափակվել, և վկայագիրը չի լրացել։ Ինչ-որ մեկը վերջնակետի հոսթի անունը փոխարինել է այդ լուծված հասցեով, և ծառայությունը այլևս այնտեղ չի պատասխանում։ Արտահանված անունը այն մասն է, որը կառուցված է այդ փոփոխությանը դիմանալու համար։
Ձեր պրոֆիլի անունը կարող է այն անունը չլինել, որի համար հարցում է արվում
Client VPN-ից արտահանված պրոֆիլները սովորաբար պարունակում են remote-random-hostname։ Այդ ընտրանքը միացված ժամանակ հաճախորդը ստեղծում է մեկանգամյա պիտակ, կետով միացնում այն վերջնակետի անվանը և լուծում համակցված անունը։ Վերջնակետի գոտու wildcard գրառումը պատասխանում է ցանկացած պիտակի, դրա համար էլ հորինված նախածանցը դեռ լուծվում է, և դրա համար էլ հնարքը անտեսանելի է մնում, երբ փորձում եք ձեռքով կրկնել հարցումը։
Այսպիսով, երբ տերմինալում տեղադրում եք վերջնակետի անունը և պատասխան ստանում, դուք լուծել եք այլ անուն, քան այն, որն օգտագործում է հաճախորդը միանալու պահին։ Այդ անհամապատասխանությունը պրոֆիլում ուղղելու թերություն չէ։ Պիտակը նորից ստեղծվում է դիտավորյալ. ընտրանքը թույլ չի տալիս քեշերին պահել հնացած պատասխան, և այն երբեք չի նույնականացնում ձեր մեքենան կամ նստաշրջանը։
Ես հանդիպել եմ համատեղելիության դեպքի, երբ հաճախորդը լիովին անտեսում է ընտրանքը։ AWS-ը փաստագրում է լուծումը. պահեք իրական վերջնակետի անունը և առաջ ավելացրեք պատահական տող ու կետ՝ դիտարկելով այն որպես անվանման ձևաչափ, ոչ թե տեղադրելու արժեք։ Դա հին հաճախորդի վրա կիրառելը խելամիտ է. նախածանցով տողը որպես վերջնակետ կոշտ կոդավորելը՝ ոչ։
Ինչու պահված պատասխանը չի կարող ճիշտ մնալ
Client VPN վերջնակետի հասցեները կառավարում է AWS-ը և դրանք ժամանակի ընթացքում փոխվում են, ինչը լավագույն փորձերի փաստաթուղթն ուղղակիորեն ասում է։ Գրանցված պատասխանը մեկ լուծման պահապատկեր է։ Այն կոշտ կոդավորող պրոֆիլը դառնում է շահագործումից հանված հոսթի ուղղված պրոֆիլ հենց որ ծառայությունը տեղափոխվի, և ձախողումը հազվադեպ է նմանվում DNS-ի. ստանում եք միացման ժամկետի սպառում կամ կանգնած handshake, այդ պատճառով մարդիկ ընկնում են երթուղման և վկայագրերի հետևից։
Նույն պատասխանը /etc/hosts-ում ժառանգում է նույն ժամկետը՝ լրացուցիչ խնդրով։ hosts գրառումը վերապրում է վերագործարկումները, վերաարտահանումները և 'վերատեղադրիր հաճախորդը' ուղղումները, այդ պատճառով ձախողումը վերադառնում է ամեն անգամ, երբ հասցեն տեղափոխվում է։ Ես տեսել եմ, թե ինչպես մեկը շաբաթներ շարունակ անվնաս մնաց, ապա շարքից հանեց այն կրող յուրաքանչյուր մեքենա, մինչ նոր տեղադրումները նորմալ միանում էին։ Այդ բաժանումը՝ մի խումբ ձախողվում է, մյուսը՝ նույն հաշվում լավ է, ամենաէժան հուշումն է, որ կստանաք։
Ճիշտ սահմանափակեք նաև պատահականացումը։ Այն տեղի է ունենում յուրաքանչյուր միացման փորձի համար։ Հաստատված թունելը նորից չի լուծում իր վերջնակետը, նստաշրջանի կեսին սերվեր չի փոխում, և առանձին հավելվածային հարցումները յուրաքանչյուրը նոր VPN հոսթ չեն ընտրում։ Միայն հաջորդ փորձն է նորից լուծում, դրա համար էլ ամբողջ կեսօր աշխատող նստաշրջանը ոչինչ չի ասում վաղը առավոտվա մասին։
Ինչ է ստուգում ծառայությունը, երբ թունելը բարձրանում է
Client VPN-ը պահանջում է, որ ձեր միացած հասցեն համընկնի վերջնակետի DNS անվան համար լուծված հասցեի հետ։ Այդ մեկ պահանջը բացատրում է անկապ թվացող մի քանի ձախողումներ. այլ տեղ ուղղված հատուկ DNS գրառում, հատուկ frontend, որը փոխանցում է վերջնակետի իրական հասցեին, և չմշակված հասցեի վերագրված պրոֆիլ։ AWS-ը հատուկ գրառում գումարած փոխանցում ձևավորումը փաստագրում է որպես ձախողում AWS-ի նոր հաճախորդների հետ։ Ստուգումը նեղ է. դա դատավճիռ չէ, որ ամեն այլանուն արգելված է։
Սա նաև VPN արձանագրությունների մասին ընդհանուր կանոն չէ։ Թվային remote-ը լիովին վավեր է սովորական OpenVPN տեղակայման մեջ, և շատերը այդպես են աշխատում։ Սահմանափակումը գալիս է կառավարվող կարգավորումից, ոչ թե դրա տակի արձանագրությունից։
Ինչը վկայագրի ստուգումը թուլացնելը դարձնում է սխալ ռեֆլեքս։ Եթե հասցեի փոխանակումից հետո պրոֆիլը ձախողվում է, սերվերի ստուգումն անջատելը տեղափոխում է սխալը՝ փոխարենը լուծելու լուծումը կամ հասցեի համապատասխանության պահանջը, և թողնում է հաճախորդ, որը կվստահի ամեն ինչի։ Պահեք արտահանված CA-ն, սերվերի ստուգումը և փոխադարձ նույնականացման կարգավորումները ճիշտ այնպես, ինչպես եկել են։
Թույլատրող ցանկերը, ելքը և մասնավոր DNS-ը երեք առանձին խնդիր են
Firewall կանոնը, որը պետք է թույլ տա նպատակակետը մինչ նոթբուքը միանալը, վերաբերում է արտաքին լսողին։ Տվեք ցանցի սեփականատիրոջը վերջնակետի անունը, տրանսպորտը և կարգավորված պորտը, ապա հարցրեք՝ կարո՞ղ է նրանց վերահսկողությունը հետևել ծառայության DNS վարքագծին։ Մեկ գրանցված հասցե պահող կանոնը չգրված ժամկետով պահապատկեր է։ Եթե վերահսկողությունն ընդունում է միայն անփոփոխ նպատակակետեր, լուծեք այդ բացը տեղակայումից առաջ՝ փոխարենը լուռ կոշտ կոդավորելու պատասխանը։
Գործընկերը, որին պետք է ֆիքսված աղբյուրի հասցե թունելը բարձրանալուց հետո արվող հարցումների համար, ունի այլ պահանջ՝ ելք։ Ինչ տեսնում է կայքը, կախված է հավելվածի երթուղուց և բաժանված թունելի քաղաքականությունից, ոչ թե այն հասցեից, որին միացել է հաճախորդը։ Բաժանված թունելի երթևեկությունը կարող է ընդհանրապես չդիպչել AWS-ին։
Թունելի ներսում մասնավոր DNS-ը երրորդ շերտն է։ Հաճախորդներին տրվող լուծիչը միանալուց հետո պատասխանում է ներքին անուններին. այն չի կարող լուծել հանրային վերջնակետը, քանի դեռ թունելը գոյություն չունի։ Վերջնակետի լուծման ձախողումը և ներքին հավելվածի լուծման ձախողումը տեղի են ունենում տարբեր փուլերում, և դրանք խառնելը ձեզ ուղարկում է սխալ մատյան։
Հասցեների ընտանիքը նույն ցանկում է։ IPv4 պատասխանը ոչինչ չի ասում IPv6 կամ կրկնակի կույտ վերջնակետի թույլատրված ուղու մասին, այդ պատճառով մեկ ընտանիքում արված պահապատկերը ապացույց չէ մյուսի համար։
Ստուգեք միացումը՝ առանց որևէ բան ամրագրելու
Սկսեք պրոֆիլից այնպես, ինչպես արտահանվել է, և կարդացեք, թե իրականում ինչ է պահանջում.
grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'Ապա համեմատեք երեք բան. պրոֆիլում եղած վերջնակետի անունը, հաճախորդի հաղորդած հասցեն նոր փորձի համար, և ինչի է անունը լուծվում հիմա։ Լուծվող անունը միայն ապացուցում է, որ գրառումը պատասխանում է. տրանսպորտը և նույնականացումը առանձին են, և վերջնակետը պարտավոր չէ պատասխանել ping-ին։ Հաճախորդի սեփական մատյանը միջին կետի միակ աղբյուրն է, այդ պատճառով գրանցեք այն փորձի ընթացքում, ոչ թե հետո։
| What you see | Usual cause | Next check |
|---|---|---|
| One machine fails, others connect | Pinned address or stale hosts entry on that machine | Diff its profile and hosts file against a working copy |
| Everyone fails at once, no config change | The endpoint address rotated | Confirm the current endpoint configuration with the account owner |
| Tunnel up, internal names fail | Client DNS policy, not endpoint resolution | Inspect the resolver pushed after connection |
Այսօր պատասխանող հասցեն այսօրվա մասին ապացույց է. անունն այն է, ինչ ծառայությունը պահում է վավեր։ Գրանցեք դիտարկումը, ուղարկեք այն վերջնակետի սեփականատիրոջը, և թողեք պրոֆիլը ցույց տա անվանը։
Երկու սովորություն թողեք. վկայագրի ստուգումներն անջատելը կանգնած handshake-ը հաղթահարելու համար, և պիտակներ կուտակելը վերջնակետի անվան առաջ՝ հույսով, որ մեկը կմնա։ Պիտակը լուծվում է wildcard գրառումով, կամ խնդիրը այլ տեղ է։ Եթե ճիշտ կարգավորված պրոֆիլը դեռ ձախողվում է, ուղարկեք ճշգրիտ հարցումը և միացման իրադարձությունը, ոչ ավելի երկար հոսթի անուն։
Նախքան փակելը. պրոֆիլը դեռ կրում է արտահանված վերջնակետի անունը, ոչ մի hosts ֆայլ չի ամրագրում հասցեն, հաճախորդի մատյանի remote-ը համընկնում է ընթացիկ լուծման հետ, և firewall կանոնը նշում է վերջնակետը, ոչ հասցե։ Սա նաև այն վիճակն է, որ պետք է հանձնել հաջորդ մարդուն։