Երկու DNS անուն, մեկ OpenVPN պորտ. ինչն է իրականում ընտրում

Երկու A գրառում, մեկ հասցե, մեկ դեմոն. ինչ անուն էլ օգտվողը մուտքագրի, ժամանող փաթեթը նույնն է, և 1194 պորտին կապված գործընթացը ոչինչ չունի դրանք տարբերելու համար։ Սա վերանորոգման սպասող սխալ կարգավորում չէ. սա այն սահմանն է, ինչը կարող է արտահայտել անվան որոնումը։ Ամեն ինչ, որ ընտրում է երկու OpenVPN օրինակների միջև, պետք է լինի արժեք, որը հաճախորդը դնում է միացման մեջ և որը ճակատային մասը կարող է հետ կարդալ, իսկ ստանդարտ OpenVPN հաճախորդը նման արժեք բացահայտ չի դնում։ Հետևյալը ցույց է տալիս, թե դա որտեղ է թողնում ձեզ և որ դասավորություններն են իրապես բաժանում երթևեկությունը։

Սկսեք նրանից, ինչ վերադարձնում է լուծիչը

Հաճախորդը հարցնում է vpn-a.example և ստանում հասցե. այդ հասցեն գումարած պորտը այն ամենն է, ինչ նա հավաքում է։ Անունը ծախսվում է տեղում՝ որոնման ընթացքում, և երբեք չի դառնում դաշտ լարի վրա, ուստի մյուս կողմի լսողը չի կարող տեսնել, թե որ պիտակն է օգտագործվել։ Ուղղեք vpn-a.example և vpn-b.example մեկ հոսթի, և երկու որոնումներն էլ կտան նույն նպատակակետը, դրա համար էլ դեմոնը կլանում է երկու միացումներն էլ մեկ օրինակի մեջ՝ առանց տարբերություն գրանցելու։ Հասցեի վրա հիմնված պրոֆիլները վարվում են ճիշտ այնպես, ինչպես անվան վրա հիմնվածները, նույն պատճառով։

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

Միակ հաշվվող ընտրիչը գնում է փաթեթի ներսում

HTTP-ն դա լուծում է Host վերնագրով, իսկ TLS-ը՝ ClientHello-ում սերվերի անվան ընդլայնմամբ, և այդպես մեկ հասցեն սպասարկում է շատ կայքեր մեկ լսողի հետևում։ Երկուսն էլ աշխատում են, որովհետև լարի արձանագրությունը կրում է հարցում կոնկրետ ծառայության համար։ OpenVPN-ի մասին էական փաստն այն է, որ այդ դաշտերից ոչ մեկը չկա այն շերտում, որը զննում է միջանկյալ արկղը։

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

Որտեղ արձանագրության բաժանիչը կանգ է առնում

Այն տեսակի մուլտիպլեքսորը, որը փաստագրում է sslh նախագիծը, լսում է մեկ պորտի վրա, զննում բացող բայթերը և միացումը հանձնում այն backend-ին, որը խոսում է ճանաչված արձանագրությամբ։ Սա իրական արժեք է, երբ մեկ պորտը պետք է միաժամանակ սպասարկի SSH, HTTPS և OpenVPN։

sslh-ը յուրաքանչյուր արձանագրության համար առանձին զոնդ է պահում, և նրա TLS զոնդը կարող է իսկական ClientHello-ից հանել սերվերի անուն կամ ALPN արժեք։ Սեփական OpenVPN-ը ճանաչելը այլ դասակարգում է, քան TLS ընդլայնում կարդալը, և երկուսը չեն միավորվում, որովհետև հաճախորդը, որը երբեք ClientHello չի ուղարկում լսող սոքեթին, զոնդը թողնում է առանց կարդալու բանի։ Այդ պատճառով OpenVPN-ին համապատասխանող կանոնը պատասխանում է «սա OpenVPN հաճախորդ է» և առաջ չի գնում։ Այդ կանոնի հետևում գտնվող երկու OpenVPN backend անտարբերելի են, ճակատային մասը ընտրության հիմք չունի, և ամեն նստաշրջան վայրէջք է կատարում նույն տեղում։ Մուլտիպլեքսավորումը մեկ պորտը կիսում է տարբեր ծառայությունների միջև. այն վիրտուալ հոսթինգ չի անում մեկ ծառայության ներսում։

Դասավորություններ, որոնք իրապես բաժանում են երկու սերվեր

Ամենաէժան ազնիվ բաժանումը երկրորդ հանրային հասցեն է՝ մեկը յուրաքանչյուր օրինակի համար, և գոյություն ունեցող պրոֆիլներն արդեն կրում են անհրաժեշտը, որովհետև ուղղված են տարբեր հասցեների։ Հաջորդը նույն հասցեի վրա այլ պորտն է, ինչը ոչինչ չի արժենա, բացի յուրաքանչյուր պրոֆիլի մեկ թվից։ TCP-ն և UDP-ն առանձին պորտային աղյուսակներ են պահում, ուստի 1194/tcp և 1194/udp-ը անկապ սոքեթներ են և յուրաքանչյուրից մեկը կարող է գոյակցել մեկ հոսթի վրա. սա տրանսպորտի բաժանում է, ոչ թե անվանով երթուղավորում, և հաճախ շփոթում են դրա հետ։ Երկու տարբերակներն էլ անցնում են հրային պատի վերանայումից, որովհետև կանոնը համապատասխանում է մի բանի, ինչ փաթեթն իրականում պարունակում է։

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

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

Ապացուցեք ընտրիչը նախքան կառուցելը

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

ss -lntup | grep -E ':443|:1194'
openssl s_client -connect vpn-a.example:443 -servername vpn-a.example </dev/null | head -n 20
journalctl -u openvpn-server@server-a -n 20 --no-pager

openssl տողը վկայագիր է տալիս միայն այնտեղ, որտեղ ինչ-որ բան այդ հասցեում ավարտում է TLS. սեփական OpenVPN լսողի դեմ այն կանգ է առնում կամ ձախողվում, և դա ինքնին պատասխանն է այն մասին, թե ինչ է բացահայտում արտաքին շերտը։ journal տողը, կարդացված յուրաքանչյուր backend-ում, ցույց է տալիս, թե որ օրինակն է ընդունել նստաշրջանը։ Ճակատային մասի մատյանները գրանցում են, թե ինչ դասակարգվեց և երբեք այն, ինչ նախատեսված էր, ուստի backend-ը մնում է միակ իշխանությունը այն հարցում, թե որտեղ է վայրէջք կատարել օգտվողը։

Ավարտեք երկու պրոֆիլներով, որոնք նախատեսված են տարբեր սերվերների հասնելու համար, միացրեք դրանք մեկ առ մեկ և գրանցեք backend-ի մատյանը յուրաքանչյուրի համար։ Եթե երկու նստաշրջաններն էլ հայտնվեն նույն journal-ում, ընտրիչը բացակայում է, այլ ոչ թե սխալ է կարգավորված, և ուղղումը հասցե կամ պորտ է, որը հաճախորդը կարող է թիրախավորել։ Երթուղավորման կանոնը խմբագրելը չի օգնի, որովհետև կանոնին երբեք ոչինչ չի տրվել, ինչի վրա երթուղավորի։ Երբ բաժանումն իրական է դառնում, գրեք այն պրոֆիլների կողքին, որպեսզի հաջորդ մարդը երկրորդ կեղծանուն չավելացնի և չսպասի, թե այն կկատարի աշխատանքը։