SOCKS5 վստահված սերվեր OpenVPN-ի համար՝ TCP թունել, թե՞ հավելվածների վստահվածացում

Ցանցերը, որոնք թույլ են տալիս ելք միայն վստահված սերվերի միջոցով, այն տեղն են, որտեղ աշխատող պրոֆիլը հանկարծ մահանում է։ Վստահված սերվերի հասցեն այդ ձախողման ամենաքիչ հետաքրքիր փոփոխականն է։ Ամեն ինչ որոշում է այն երթևեկության ձևը, որը վստահված սերվերը կփոխանցի, որովհետև այս վստահված սերվերները փոխանցում են բայթային հոսք, իսկ UDP թունելն այդպիսին չէ։ Սա թողնում է երկու ճարտարապետություն, և դրանք կոտրվում են տարբեր տեղերում։

Մեկ սահմանափակում որոշում է ձևավորումը

SOCKS5-ը իսկապես սահմանում է UDP միացման ռեժիմ։ Այնուամենայնիվ, OpenVPN հաճախորդի վստահված սերվերի աջակցությունը կառուցված է հոսքերի շուրջ՝ socks-proxy փաստաթղթավորված է TCP պրոֆիլների համար, և HTTP CONNECT վստահված սերվերը բոլորովին չունի ուղի տվյալագրման միավորների համար։ Փաստաթղթի մեկ տողը որոշում է ճարտարապետությունը, նախքան կարգավորումների ֆայլին կպնելը։

Հետևաբար հարցը այն չէ, թե որ վստահված սերվերն ընտրել։ Հարցն այն է՝ թունելը դառնում է հոսք, թե՞ մնում է տվյալագրման միավոր և թույլ է տալիս մեկ այլ բանի կլանել վստահվածացումը։

Տարբերակ Ա՝ թունելը դարձնել հոսք

Սա պահանջում է սերվեր TCP լսողով և հաճախորդի պրոֆիլ, որը նշում է վստահված սերվերը։ Երկու մասերն էլ անհրաժեշտ են, և սերվերի կողմն այն է, ինչը մարդիկ մոռանում են՝

proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080

Փոխարինեք վերջին տողը http-proxy proxy.internal 8080-ով, երբ վստահված սերվերը խոսում է HTTP-ով, և ավելացրեք հավատարմագրերի ֆայլ, եթե պահանջում է։ Վստահված սերվերը պետք է պատրաստ լինի CONNECT կատարել ձեր VPN պորտին, և սերվերը պետք է պատասխանի TCP-ով, միայն UDP լսողը անտեսում է փորձը։ 443-ի ընտրությունը գործնական քայլ է, որովհետև շատ սահմանափակող ցանցեր թույլ են տալիս դա և քիչ այլ բան։

Գինը TCP-ն TCP-ի վրա դնելն է։ Մեկ կորցրած արտաքին հատվածը կանգնեցնում է այդ միացումը կիսող յուրաքանչյուր ներքին հոսք, ուստի վերականգնումը, որը սովորաբար անկախ կլիներ, դառնում է համատեղ։ Կարգավորումը նույնպես ավելի երկար է տևում, և անկայուն արտաքին ուղին դառնում է անկայուն թունել՝ դանդաղի փոխարեն։

Տարբերակ Բ՝ թունելը թողնել հանգիստ

Երբ թունելը պետք է մնա UDP-ի վրա, թունելը այն տեղը չէ, որտեղ ինչ-որ բան եք կարգավորում։ Փոխարենը, հավելվածներից ելքային TCP-ն վերահասցեավորվում է տեղական SOCKS լսողի, և հավելվածները երբեք չեն իմանում, որ վստահված սերվեր գոյություն ունի։ Linux-ում դա սովորաբար redsocks է՝ գումարած NAT REDIRECT կանոն nat աղյուսակում։

Կրկին միայն TCP։ Միայն HTTP վստահված սերվերը, ինչպիսին privoxy-ն է, չի կարող փոխանցել կամայական արձանագրություններ, և այս ձևավորումը հավելվածների համար տվյալագրման միավորների աջակցություն չի ավելացնում։

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

Որտեղ է ձախողվում յուրաքանչյուր տարբերակ

Տարբերակ Ա-ն ձախողվում է, երբ սերվերը չունի TCP լսող, երբ վստահված սերվերը մերժում է CONNECT նպատակը, կամ երբ արտաքին հոսքը սահմանափակվում է թունելի պահանջից ցածր։ Առաջին երկուսը գրառում են թողնում վստահված սերվերի մատյանում՝ երրորդը թողնում է միացում, որը հաստատվում է և հետո սխալ է թվում։ Կարդացեք այդ մատյանը պրոֆիլը խմբագրելուց առաջ, որովհետև այն թույլտվության խնդիրը տարանջատում է թողունակության խնդրից։ Ավարտված CONNECT-ը հետաքննությունը տեղափոխում է թունելի ներս։

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

Ոչ մի տարբերակ չի փոխում սարքի պահանջը։ Փաթեթները դեռևս կարիք ունեն TUN կամ TAP հանգույցի, նախքան միջուկը կերթուղավորի դրանք, ուստի գործընթացը դեռևս թույլտվության կարիք ունի /dev/net/tun-ի վրա։ Փաթաթան փոխում է այն, ինչ տեղի է ունենում այդ հանգույցը բացելուց հետո, ոչ թե այն՝ արդյոք ձեզ պետք է այն։

Ապացուցեք, թե որ ուղին եք կառուցել

Նայեք սվոկետներին, ոչ թե սկուտեղի պատկերակին։ VPN գործընթացը պետք է պահի հաստատված միացում վստահված սերվերի հասցեին, և վստահված սերվերը պետք է գրանցած լինի այն նպատակը, որին խնդրվել էր հասնել՝

ss -tnp | grep openvpn

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

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