Ինչու nc -uz-ը չի կարող ապացուցել, որ OpenVPN սերվերը պատրաստ է

Գործարկելը nc -uz դեմ OpenVPN սերվերի գրեթե ոչինչ չի չափում, և OpenBSD ձեռնարկը դա ասում է իր նախազգուշացումներում՝ այդ ռեժիմում UDP սկանավորումները հաջողություն են հաղորդում անկախ նրանից՝ ինչ-որ բան լսում է, թե ոչ։ Ելքի կարգավիճակը արտացոլում է տեղական ուղարկումը, ոչ թե հեռավոր վիճակը, ուստի դրան վստահող վերահսկիչը մեռած սերվերը պահում է որպես առողջ նշված, քանի դեռ գործընթացների աղյուսակը հավաստի է թվում։ Այն փոխարինելը սկսվում է որոշելով, թե որ հարցին պետք է պատասխանի ստուգումը, որովհետև գործընթացը, լսողը, նույնականացումը և հավելվածի հասանելիությունը չորս տարբեր դիտարկումներ են։ Ստուգումը, որը նշում է դրանցից մեկը, օգտակար է, իսկ ստուգումը, որը ենթադրում է բոլոր չորսը, բեռ է։

Ինչ կարող է և ինչ չի կարող դիտարկել UDP ստուգումը

nc -uz ուղարկում է դատագրամ և դուրս գալիս, և վերադարձված կարգավիճակը նկարագրում է տեղական ուղարկումը։ Փակ պորտը կարող է պատասխանել ICMP port unreachable-ով, սակայն այս սկանավորման ռեժիմի փաստաթղթավորված վարքը դա ձախողման չի վերածում, իսկ զտված պորտը ընդհանրապես պատասխան չի տալիս։ Ուստի լռությունը և հաջողությունը կանչողի համար նույն բանն են նշանակում։

Դա ստուգումը դարձնում է տեղական կույտի, այլ ոչ թե սերվերի փորձարկում։ Այն չի հաստատում, որ հոսթը հասանելի է, պորտը կապված է, OpenVPN գործընթացը աշխատում է կամ որ հաճախորդը կկարողանար նույնականանալ։ TCP միացման փորձարկումն ավելի ուժեղ է, քանի որ ձեռքսեղմումը հստակ պատասխան է տալիս, բայց միայն այն դեպքում, երբ տեղակայումն իրոք լսում է TCP-ով։ Ստուգումը նույն համարի վրա TCP-ի տեղափոխելը փորձարկում է լսող, որը գուցե չկա, իսկ միայն UDP-ով սերվերի դեմ այն կձախողի առողջ ծառայությունը։

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

Երեք կանչող, երեք տարբեր հարցեր

Պատրաստվածությունը կախված է նրանից, թե ով է հարցնում։ Ծառայության կառավարիչը, որը վերագործարկում է ընկած գործընթացը, պետք է իմանա, որ օրինակը մեկնարկել է և կապել իր լսողին։ Բեռնվածքի հավասարակշռիչը պետք է իմանա, որ հիմա ժամանող հաճախորդը կընդունվի։ Մոնիտորինգի համակարգը պետք է իմանա, որ իրական ցանցից ուղին դեռևս նստաշրջան է տանում թույլատրված ռեսուրս։

Սրանք նույն ստուգումը չեն, և մեկ ստուգում չի կարող ազնվորեն ծածկել բոլոր երեքը։ Նախ ընտրեք կանչողին, ապա ապացույցը։

Կառուցեք ստուգումը ընթացիկ օրինակից

OpenVPN-ը մեկնարկային տող է գրում, երբ օրինակը ավարտում է նախաձեռնումը, և այդ տողը օգտակար ապացույց է տեղական մեկնարկի մասին։ Կարդացեք այն ընթացիկ մեկնարկից, ոչ թե ավելացվող ֆայլի վերջից, որովհետև անցյալ շաբաթվա հաջողությունը կարդացվում է ճիշտ այնպես, ինչպես մեկ րոպե առաջվա հաջողությունը։ Սերվերը կարող է նաև ավարտել նախաձեռնումը նախքան որևէ հաճախորդի երբևէ միանալը, ուստի տողը ոչինչ չի ասում նույնականացման մասին։

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

systemctl is-active openvpn@server
sudo journalctl -u openvpn@server -b --no-pager | grep "Initialization Sequence Completed"
ss -lunp | grep 1194

Երեք ելք, երեք պնդում՝ միավորը ակտիվ է, այս բեռնումն առաջացրել է նախաձեռնման տողը, և ինչ-որ բան պահում է UDP պորտը։ Դրանցից ոչ մեկը չի ասում, որ հաճախորդը կարող է միանալ։ Պահեք դրանք առանձին կարգավիճակի էջում, որպեսզի միջադեպը չսեղմվի մեկ կանաչ կետի։

Կոտրեք այն դիտավորյալ և դիտեք ստուգումը

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

sudo systemctl stop openvpn@server
nc -uz 203.0.113.10 1194; echo "exit=$?"
ss -lunp | grep 1194
sudo systemctl start openvpn@server
ss -lunp | grep 1194

Կարդացեք բլոկը տող առ տող։ netcat հրամանը տպում է exit=0 մինչ ոչինչ կապված չէ, և դա ամբողջ խնդիրն է մեկ տողում։ Առաջին ss ոչինչ չի տպում, վերագործարկումը հաջողվում է, իսկ երկրորդը ss նորից ցույց է տալիս լսողին։ Եթե ձեր ստուգումը անցնում է կանգնեցված սերվերի դեմ, ապա այն չափում է տեղական կույտը և ուրիշ ոչինչ։

Հակառակ ձախողումը նույնպես կարևոր է։ Առողջ սերվերի դեմ ձախողվող ստուգումը առաջացնում է վերագործարկումներ, որոնք երբեք պետք չէին, և վերագործարկման հանգույցն ինքնին ընդհատում է։ Փորձարկեք երկու ուղղությունները նախքան ստուգումը միացնելը որևէ բանի, որը կարող է գործել դրա հիման վրա։

Ինչ պետք է ասի կարգավիճակի տողը

Գրանցեք, թե որ սահմանն է ծածկում յուրաքանչյուր ստուգում՝ գործընթաց, լսող, նույնականացում կամ հավելված։ Մեկ ստուգումը հազվադեպ է ծածկում մեկից ավելին, և կարգավիճակի էջը, որը դրանք սեղմում է “up”-ի մեջ, թաքցնում է այն տարբերությունը, որը կարևոր է միջադեպի ընթացքում։ Ցանցային ուղու համար օգտագործեք իրական հաճախորդ՝ հատուկ ինքնությամբ, թողեք նրան ավարտել ձեռքսեղմումը և մեկ անվնաս թույլատրված գործողություն, ապա անջատեք։ Դա մեկ քայլով վարժեցնում է կառավարման ալիքը, նույնականացման քաղաքականությունը և լսողը։

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

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