OpenVPN և HTTPS 443 պորտում. ո՞ւմն է լսողը
TCP և UDP 443-ը առանձին բնիկներ են։ Մեկ TCP լսողի համօգտագործումը պահանջում է սեփականատեր, իսկ OpenVPN-ի պորտի համօգտագործումը նեղ պայմանավորվածություն է, ոչ թե վստահված անձի հնարք։
Երկու ծառայություն կարող են միաժամանակ պատասխանել 443 պորտին՝ երբեք չմրցելով, որովհետև լսողը որոշվում է տրանսպորտով, հասցեով և պորտով միասին, ոչ միայն համարով։ Տեղադրեք վեբ սերվեր և OpenVPN մեկ մեքենայի վրա, և միակ հարցը, որ արժե առաջինը պատասխանել, այն է, թե յուրաքանչյուր գործընթաց որ բնիկն է խնդրում միջուկից։ Գրեք այդ ցանկը նախքան կարգավորումը խմբագրելը, և «հասցեն արդեն օգտագործվում է» սխալների մեծ մասը ինքնին կբացատրվի։ Ցանկից հետո ամեն ինչ ընտրություն է UDP լսողի, համօգտագործվող TCP բնիկի կամ ըստ արձանագրության երթուղավորող ճակատային մասի միջև։
Սկսեք այն բնիկից, որ խնդրում է յուրաքանչյուր գործընթաց
bind-ը հաջողվում կամ ձախողվում է այդ եռյակով, ուստի երկու դեյմոն բախվում են միայն այն ժամանակ, երբ բոլոր երեք մասերը համընկնում են։ Այդ պատճառով TCP 443-ի վրա կայքը անսահմանափակ գոյակցում է UDP 443-ի OpenVPN լսողի հետ, և այդ պատճառով դրանցից մեկը նույն հոսթի երկրորդ տեղական հասցե տեղափոխելը նույնպես վերջ է դնում վեճին։ Կարդացեք կենդանի լսողներին, ոչ թե այն ֆայլերը, որոնք պետք է ստեղծեին դրանք, որովհետև հնացած include-ը կամ մոռացված unit ֆայլը ապրում է ավելի երկար, քան ձեր հիշած խմբագրումը։
| Line in the listener list | What it establishes | What to do next |
|---|---|---|
| One udp row and one tcp row, each on 443 | Separate transport sockets, nothing contested | Point the VPN profile at udp and stop editing |
| A single tcp address and port listed by two processes | A real bind collision between two daemons | Move one service, or put a dispatcher in front of both |
| A proxy process owns the socket, no vpn process | The proxy accepts and has to hand off correctly | Check that its backend speaks the protocol it forwards |
Գործարկեք ss -lntup-ը root-ով և կարդացեք 443-ը հիշատակող յուրաքանչյուր տող, ներառյալ IPv6 գրառումները։ v6-ի համընդհանուր լսողը սովորաբար ընդունում է նաև v4 երթևեկությունը, և այդպես է, որ մոռացված լսողը պորտը զբաղեցված է պահում այն բանից հետո, երբ փոխում եք այն ֆայլը, որը պատասխանատու էիք համարում։ Եթե գործընթացի անունը զարմացնում է ձեզ, նեղացրեք ելքը ss -lntup 'sport = :443'-ով նախքան որևէ բանի դիպչելը։
Անցեք թունելը UDP-ի, երբ ցանցը թույլ է տալիս
UDP լսողը ամբողջությամբ շրջանցում է բախումը և սովորաբար ամենակարճ վերանորոգումն է, քանի որ ոչ մի բնիկ չի համօգտագործվում և ոչ մի լրացուցիչ արտադրանք չի մտնում ուղի։ Բայց դա անվճար չէ։ Որոշ հաճախորդային ցանցեր գցում են UDP 443-ը առանց reset ուղարկելու, ուստի թունելը դադարում է հաստատվել bind-ում ձախողվելու փոխարեն, և օգտատերը հայտնում է, որ VPN-ը անջատված է՝ առանց կարդալու սխալի։ UDP լսողը նաև վերապրում է վեբ շերտի վերագործարկումը, ինչը կարևոր է մի մեքենայի վրա, որի կայքը հաճախ վերատեղակայվում է։ Փորձարկեք այն ցանցից, որտեղ նստած են օգտատերերը, որովհետև սերվերի shell-ը միայն ապացուցում է, որ սերվերը հասնում է ինքն իրեն։
Փոխեք տրանսպորտը սերվերի կարգավորումում և հաճախորդի պրոֆիլում միասին։ Պրոֆիլը, որը դեռ TCP է խնդրում, կպտտվի վերակապակցումների ցիկլերում միայն UDP լսողի դեմ, և դա ցանցային խափանման տեսք ունի, քանի դեռ չեք համեմատել երկու ֆայլերը։
Թող VPN գործընթացը տիրապետի TCP 443-ին, իսկ մնացածը փոխանցվի
Community OpenVPN-ը TCP սերվերի ռեժիմում կարդում է ներգնա կապի առաջին բայթերը և ամեն ինչ, որ իր արձանագրությունը չէ, փոխանցում է HTTPS հետնամաս, ինչի համար էլ port-share հրահանգն է։ Հետնամասը սովորական վեբ սերվեր է՝ TLS-ով միացված, որը այդ հրահանգում անվանվում է հոսթով և պորտով, ոչ թե URL-ով։
port-share 10.0.0.5 8080
Մի մեքենայում, որտեղ կայքն ունի երկրորդ մասնավոր հասցե, այդ տողը ոչ VPN երթևեկությունն ուղարկում է 10.0.0.5:8080, ուստի HTTPS վիրտուալ հոսթը պետք է այնտեղ կապված լինի, և firewall-ը պետք է թույլ տա տեղական թռիչքը։ Վեբ սերվերը պետք է ինքը վերջացնի TLS-ը, որովհետև ժամանող բայթերը զննարկչի բնօրինակ ձեռքսեղմումն են, և մեջտեղում ոչինչ չի ապակոդավորել դրանք։ Ուղղեք հրահանգը սովորական HTTP լսողի, և զննարկիչը կստանա անվավեր մեթոդի սխալ, որը կարդացվում է որպես կոտրված կայք, ոչ թե սխալ տեղադրված հետնամաս։ Հրահանգը գոյություն ունի միայն TCP սերվերի ռեժիմում, և UDP լսողը ստուգելու հոսք չունի։
Քանի որ VPN գործընթացն ընդունում է ամեն կապ, վեբ հավելվածը տեսնում է փոխանցված հարցումը գալիս հոսթի սեփական հասցեներից մեկից, ոչ թե այցելուից։ Ամեն ինչ, ինչին պետք է իրական հաճախորդի հասցեն, կախված է հետնամասում PROXY արձանագրության աջակցությունից կամ այն ավելացնող ճակատային մասից։ Հետնամասը մեկ այլ տեղական հասցե տեղափոխելը չի վերադարձնում այցելուի հասցեն. այն միայն փոխում է, թե հոսթի որ հասցեներն է կայքը գրանցում։ Գրեք այդ սահմանափակումը տեղակայման նշումներում նախքան վերլուծական հաշվետվությունը հարց կբարձրացնի։
Հակադարձ վստահված անձը սխալ գործիք է, չորրորդ շերտի երթուղիչը՝ ոչ
HTTP հակադարձ վստահված անձը վերջացնում է TLS-ը, որպեսզի կարողանա կարդալ հարցումները, ինչը նշանակում է, որ այն չի կարող OpenVPN հոսքն անձեռնմխելի անցկացնել։ Չորրորդ շերտի երթուղիչը, որը փոխանցում է ըստ SNI-ի կամ առաջին փաթեթի զննման, կարող է կանգնել երկուսի առջև, պայմանով, որ չի ավարտում այն սեսիան, որից կախված է VPN-ը։ Երկու սարքերը դիագրամում նման են երևում և բնիկի մոտ բոլորովին այլ կերպ են վարվում։
Առևտրային Access Server-ը բերում է պորտի համօգտագործման իր կարգավորումները, և դրանք մեկ առ մեկ չեն համապատասխանում համայնքային հրահանգին։ Որոշեք արտադրանքը և տարբերակը նախքան մյուսի համար գրված ուղեցույցը հարմարեցնելը։ Լուռ անտեսված պատճենված կարգավորումը ավելի վատ է, քան կարգավորման բացակայությունը, որովհետև լսողների ցանկը դրանից հետո դեռ հավաստի է թվում։
Փորձարկեք կայքը և թունելը որպես երկու առանձին ուղիներ
Բեռնեք կայքը և միացրեք թունելը, ապա նորից կարդացեք լսողների ցանկը՝ տեսնելու, թե որ գործընթացն է հիմա տիրապետում 443-ին։ Բեռնվող էջը ոչինչ չի ապացուցում VPN-ի մասին, և միացող թունելը ոչինչ չի ապացուցում կայքի մասին, թեև երկուսն էլ օգտագործում են նույն համարը։ Ստորև երեք հրամանները ստուգում են համօգտագործվող բնիկը, վեբ ուղին և VPN ծառայությունը այդ հերթականությամբ։
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
Համեմատեք հաճախորդի հասցեն հետնամասի մուտքի մատյանում նույն պահի VPN մատյանի հասցեի հետ։ Եթե կայքը գրանցում է ամեն այցելուի որպես հոսթ ինքը, փոխանցումը աշխատում է, իսկ հասցեի մշակումը՝ ոչ։ Եթե երկու մատյաններն էլ լուռ են, ճակատային մասը երբեք չի հանձնել կապը։ Ամեն դեպքում լսողների ցանկը որոշում է, թե ով է ընդունում բնիկը, և դա այն փաստն է, որ պետք է հաստատել նախքան ևս մեկ ֆայլ փոխելը։
Թողեք այդ լսողների քարտեզը կարգավորման կողքին, որպեսզի 443-ին դիպչող հաջորդ մարդը իմանա, թե որ գործընթացն է ընդունում և ուր է գնացել մյուս արձանագրությունը։ Հաստատեք սեփականությունը փոփոխությունից հետո, փոխարենը վստահելու, թե ինչ պետք է աներ խմբագրումը։