Պորտի փոխանցումը ընդդեմ VPN մուտքի. ու՞ր է իրականում գնում փաթեթը

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

DNAT կանոնը վերագրում է նպատակակետը և կանգ է առնում այնտեղ

Linux դարպասում ծառայություն հրապարակելը նշանակում է կանոն nat աղյուսակի PREROUTING շղթայում, կամ դրա համարժեքը nftables-ում։ Կանոնը համընկնում է հանրային հասցեի և պորտի հետ, ապա վերագրում է նպատակակետը հավելվածի մասնավոր հասցեով։ Աղբյուրի հասցեն, աղբյուրի պորտը և բեռը մնում են անփոփոխ, և conntrack-ը գրանցում է քարտեզագրումը, որպեսզի պատասխանները ելքի ժամանակ նորից գրվեն։ Վարքը RFC 3022-ում նկարագրված հասցեների թարգմանության ավանդական մոդելն է։

sudo iptables -t nat -A PREROUTING -d 203.0.113.10 -p tcp --dport 443 \
  -j DNAT --to-destination 10.20.30.40:443
sudo iptables -t nat -L PREROUTING -n -v
sudo conntrack -L -p tcp --dport 443

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

Կանոնը նաև սահմանում է ձախողման եղանակները, որոնց կհանդիպեք ավելի ուշ։ Եթե դարպասը փոխանցում է, բայց հավելվածի հոսթը հետադարձ ուղի չունի դեպի հաճախորդ, պատասխանները դուրս են գալիս սխալ աղբյուրով և ձեռքսեղմումը կանգ է առնում։ Եթե երկրորդ կանոնը համընկնում է առաջինը, հերթականությունն է որոշում արդյունքը, և iptables -t nat -L -n -v ցույց է տալիս հաշվիչները, որոնք ապացուցում են, թե որ կանոնն է վերցրել փաթեթը։

Թունելը փաթաթում է փաթեթը մինչև լսողը կտեսնի այն

VPN-ը բոլորովին չի հրապարակում հավելվածը։ Հաճախորդը կառուցում է արտաքին փաթեթ՝ ուղղված դարպասի հանրային հասցեին, ներսում գաղտնագրում է ներքին փաթեթը, և դարպասը վերծանում ու ուղղորդում է ներքին փաթեթը մասնավոր նպատակակետ։ WireGuard-ում արտաքին տրանսպորտը UDP է, սովորաբար բարձր պորտում. OpenVPN-ի դեպքում TCP 443-ի վրա արտաքին փաթեթը TLS-ի տեսք ունի ուղին դիտող ամեն ինչի համար։

Թունելի ներսում ներքին փաթեթը պահում է մասնավոր հասցեներ՝ հաճախորդի թունելի հասցեն, ասենք 10.8.0.6, և հավելվածը 10.20.30.40-ում։ Այդ պատճառով լսողը տեսնում է աղբյուր թունելի լողավազանից, և յուրաքանչյուր հաճախորդ կիսում է այդ դարպասը որպես հաջորդ ցատկ։ VPN-ի հետևում մուտքի մատյանները հաճախ ցույց են տալիս դարպասը, այլ ոչ թե օգտվողին հենց այս պատճառով, եթե դարպասը չի պահպանում սկզբնական աղբյուրը։

Փաթաթումը արժե վերնագրի տարածք, և դա միակ մեխանիզմային տարբերությունն է, որն ունի չափելի հետևանք։ Արտաքին IP վերնագիրը գումարած UDP-ն գումարած WireGuard-ի սեփական վերնագիրը ուտում են ուղու MTU-ից, ուստի մեծ փաթեթները պետք է բաժանվեն, կամ ներքին TCP կույտը պետք է սահմանափակի իր MSS-ը։ Փոխանցումը, որն աշխատում է փոխանցված ուղով, կարող է կանգ առնել թունելի վրա, երբ միջանկյալ սարքը գցում է ICMP-ն, որը կհայտներ ավելի փոքր MTU-ի մասին։

ip route get 10.20.30.40
ping -M do -s 1400 10.20.30.40
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

Բացահայտվածությունը որոշվում է մուտքի մոտ, ոչ թե գաղտնագրով

Երկու նախագիծն էլ ավարտվում են նույն TLS լսողի մոտ, ուստի երկուսն էլ ժառանգում են նույն վկայագիրը, նույն արձանագրության տարբերակները և նույն հավելվածի մուտքը։ Փոխվում է այն, թե ով իրավունք ունի սկսել ձեռքսեղմում։ Հանրային փոխանցման դեպքում ցանկացած հոսթ, որը հասնում է 203.0.113.10:443, ստանում է TCP ձեռքսեղմում և TLS ClientHello նախքան ձեր հավելվածի լիազորությունը ընդհանրապես դիտարկվելը։ Միայն թունելով մուտքի դեպքում լսողը հասանելի է միայն այն հասցեներից, որոնք դարպասը ուղղորդում է թունել, և անծանոթի SYN-ը մահանում է դարպասի քաղաքականության վրա։

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

Ստուգեք լսողն ու քաղաքականությունը առանձին, որովհետև դրանցից յուրաքանչյուրը կարող է ավելի լայն լինել, քան կարծում եք.

sudo ss -ltnp 'sport = :443'
sudo nft list ruleset
openssl s_client -connect 203.0.113.10:443 -servername files.example.com </dev/null

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

Չափեք ուղին, ոչ պիտակը

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

curl -sS -o /dev/null -w '%{time_connect} %{time_appconnect} %{time_total}\n' \
  https://files.example.com/report.pdf
mtr -rwc 20 203.0.113.10
mtr -rwc 20 10.20.30.40

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

Ընտրեք այն մուտքի քաղաքականությունը, որն իսկապես անհրաժեշտ է ծառայությանը, ապա որոշեք՝ արդյոք չափված տարբերությունը արդարացնում է այն փոխելը։ Հանրային փոխանցումը հարմար է բաց ինտերնետի համար նախատեսված ծառայությանը՝ աղբյուրի սահմանափակումներով, թարմացված TLS-ով և առջևում հսկողությամբ։ Միայն թունելով մուտքը հարմար է ներքին գործիքի համար, որի օգտվողներն արդեն գրանցված են, պայմանով, որ դարպասի երթուղումը և հավելվածի թույլտվությունները երկուսն էլ ավելի նեղ են, քան ամբողջ LAN-ը։

Նախքան նախագիծը ավարտված հայտարարելը հաստատեք չորս բան. թե որ հասցեին է կապված լսողը, որ կանոնը կամ երթուղին է ներս թողնում փաթեթը, արդյոք հետադարձ ուղին աշխատում է հաճախորդի իրական հասցեից, և արդյոք մեծ բեռները դիմանում են MTU-ին։ Դրանցից յուրաքանչյուրի համար վերևում հրաման կա, և ոչ մեկին չի պատասխանում «անվտանգ» բառը կամ թողունակության գրաֆիկը։