OpenVPN AF_INET նախազգուշացում՝ անվնաս հետադարձ կամ ձախողված socket
Տարբերե՛ք AF_INET հետադարձը socket-ի ստեղծման հետագա ձախողումից. կարդացե՛ք ճշգրիտ տողը, ապա ստուգե՛ք լսողը և հաջորդ սխալը։
Երկու OpenVPN մատյանների տողեր սկսվում են նույն բառերով, և դրանցից միայն մեկն է հայտնում խնդրի մասին։ Could not determine IPv4/IPv6 protocol. Using AF_INET-ը հետադարձի ծանուցում է. պրոֆիլը թողել է հասցեների ընտանիքը բաց, ուստի դեմոնն ընտրել է մեկը և շարունակել։ Ձախողման ճյուղը հայտնում է, որ socket չի ստեղծվել և պահանջում է վերագործարկում։ Ընդհանուր նախածանցից հետո ամեն ինչ բաժանում է դրանք, ուստի կարդացե՛ք դրանից այն կողմ, նախքան որևէ բան փոխելը։
Ինչ է հայտնում հետադարձի ծանուցումը
OpenVPN-ն ընդունում է բացահայտ ընտանիք proto udp4-ի կամ proto udp6-ի միջոցով, և ընդունում է proto udp-ը, երբ ընտանիքը պետք է ստացվի գործարկման պահին։ Երկրորդ դեպքում դեմոնը զննում է տեղական կապի տեղեկությունը և ընտրում։
Երբ այդ ստացումն աշխատում է, նախազգուշացումը նշում է, թե որ ուղղությամբ գնաց, և գործընթացը շարունակում է ստեղծել socket-ը։ Կրկնակի ստեկով հոսթի վրա proto udp-ով սերվերը հաճախ այսպես է հայտնվում IPv4-ի վրա։ Այդ ճանապարհին ոչինչ սխալ չէ, և ոչինչ դրանում չի ակնարկում հարձակում, բացակայող վեբ սերվեր կամ մերժված հաշիվ։ Տողն օգտակար է միայն այն պատճառով, որ հետագա ստուգումները պետք է համեմատվեն այն ընտանիքի հետ, որը նա նշում է։
Դիտե՛ք այն որպես մեկ հարցի պատասխան, ոչ որպես ախտորոշում։ Այն ասում է, թե որ ընտանիքն է ընտրել այս գործընթացը, և ոչինչ այն մասին, թե ինչու հաճախորդը չի կարող միանալ։
Ինչպիսին է ձախողման ճյուղը
Ավելի ուշ նույն socket-ի կոդում կա ճյուղ, որտեղ socket ընդհանրապես չկա։ Այն գրանցում է հասցեների ընտանիքի ավելի կարճ հաղորդագրությունը և պահանջում վերագործարկում, որովհետև շարունակելու ոչինչ չի մնացել։ Սկզբնական բառերը համընկնում են հետադարձի հետ. արդյունքը՝ ոչ։
Տարբերե՛ք դրանք ըստ այն բանի, ինչ հաջորդում է։ Եթե դեմոնը շարունակում է աշխատել և հայտնում է իր լսողին, տողը տեղեկատվություն էր։ Եթե այն դուրս է գալիս կամ հանգույցում վերագործարկվում, խոսակցությունն այժմ կապի մասին է։
grep-ով հայտնաբերումը նույնպես ճյուղի նույնականացում չէ։ Արտահայտությունը հանդիպում է պտտվող ամփոփումներում, ծալված տողերում և մատյանների հատվածներում, որոնք մարդիկ տեղադրում են երկրորդ ձեռքից, ուստի կարդացե՛ք հարևան տողերը և ժամանակադրոշմների հերթականությունը, ոչ թե միակ համընկնումը։
Ստուգե՛ք լսողը, ոչ թե նախազգուշացումը
Աշխատող սերվերը պատասխանում է ընտանիքի հարցին ուղղակիորեն՝ առանց մատյանի տեքստից ենթադրության։
ss -lunp | grep openvpn
ss -ltnp | grep openvpnՀամապատասխանեցրե՛ք ընտանիքը, հասցեն և պորտը պրոֆիլին։ 0.0.0.0:1194 տողը միայն IPv4 է, մինչդեռ կրկնակի ստեկով հոսթի վրա [::]:1194 տողը կարող է ընդունել երկու ընտանիքներն էլ՝ կախված bindv6only կարգավորումից։ Եթե պրոֆիլը ասում է udp, իսկ socket-ը IPv4 է, հաճախորդները, որոնց լուծիչը վերադարձնում է միայն AAAA գրառում, կձախողվեն նախքան թունելի շուրջ բանակցելը։
Ապա փորձարկե՛ք ձեր օգտատերերին նման հաճախորդից. նույն լուծիչի ուղին, նույն տեսակի ցանցը։ Սերվերից տեղական միացումը շատ քիչ բան է ապացուցում NAT սարքով կամ մյուս ընտանիքի համար գրված հրապատի կանոնով անցնող թրաֆիկի մասին։
Երբ է ընտանիք պարտադրելը ճիշտ
proto udp4-ը ամրացնելը հարմար է միայն IPv4 տեղակայմանը. միայն A տիպի DNS անուն, հրապատի կանոններ մեկ v4 հասցեի համար, հաճախորդներ օպերատորների հետևում, որոնք տալիս են միայն v4 հասցեներ։ Դա վերացնում է երկիմաստությունը և դարձնում հաջորդ մատյան տողերը կանխատեսելի։
Նույն փաստարկը հակառակ ուղղությամբ գործում է IPv6-ն առաջին տեղում դնող միջավայրի համար, և միայն A հաճախորդային բազայի դիմաց udp6-ը ինքնաստեղծ ընդհատում է։ Ընտանիք պարտադրելը միայն անվնաս նախազգուշացումը լռեցնելու համար այս սխալի դասական տարբերակն է, որովհետև դուք փոխել եք, թե ով կարող է միանալ, ավելի հանգիստ մատյանի դիմաց։
Ընտրե՛ք՝ ելնելով վերջնակետերից և այն հաճախորդներից, որոնք պետք է հասնեն դրանց։ OpenVPN 2.6 ձեռնարկը փաստաթղթավորում է փոխադրման ձևերը, և հաղորդագրությունն այդ ընտրության արդյունքն է, ոչ թե դրա մուտքը։
Պահե՛ք գրառումը նեղ
Գրե՛ք ճշգրիտ տողը նրա ժամանակադրոշմով, աշխատող պրոֆիլի արդյունավետ փոխադրման կարգավորումը, socket-ը, ինչպես որ միջուկը հայտնում է, և հաջորդ փուլը, որը ձախողվեց։ Այս չորս կետերը լուծում են գրեթե բոլոր հարցերը, որ հաղորդագրությունը բարձրացնում է, և դրանցից ոչ մեկը չի պահանջում գուշակություն անկապ ծառայությունների մասին։ Դրանք նաև դիմանում են հանձնումը, ինչը grep-ի էկրանի պատկերը չի անում։
Այս նախազգուշացմանը զուգահեռ եկող փաթեթային առաջարկները անկապ են, քանի դեռ սխալը չի նշում բացակայող գործարկվող ֆայլ։
Եթե ifconfig իսկապես բացակայում է, դեմոնը դա ասում է անունով, երբ սկրիպտը կանչում է այն, և դա արժանի է առանձին հետաքննության։ AF_INET տողը և բացակայող օգտակար ծրագիրը տարբեր ձախողումներ են, և ինչ-որ բաներ տեղադրելը՝ տեսնելու, թե արդյոք նախազգուշացումը փոխվում է, այն ուղին է, որով մաքուր հոսթը դառնում է խառնաշփոթ։