NAT-ը որոշում է, թե ձեր VPN սերվերն իրականում որ աղբյուրի հասցեն է տեսնում
Ձեր նոթբուքի հասցեն երբեք չի հասնում VPN սերվերին։ NAT-ը վերագրում է այն վերջին ցատկում, իսկ թունելի IP-ն տրվում է ավելի ուշ։ Ինչպես համեմատել երկու ծայրերը։
Դուք պատկերացնում եք, թե VPN սերվերը կարդում է ձեր նոթբուքի հասցեն փաթեթից և գրում այն մատյանում։ Այն, ինչ նա կարդում է, այն է, ինչ վերջին NAT ցատկը դրել է արտաքին վերնագրում, իսկ որպես հոթսփոթ օգտագործվող հեռախոսում դա հաճախ հարյուրավոր այլ բաժանորդների հետ կիսվող հասցե է։ Ձեր մեքենայի սեփական 192.168.x.x հասցեն երբեք չի անցնում ինտերնետը այդ վերնագրում, և թունելի հասցեն սերվերը տալիս է այն բանից հետո, երբ կապն արդեն հաստատված է։ Այսպիսով, երբ սերվերի մատյանն ու նոթբուքի ip addr-ը չեն համընկնում, ոչ մեկը սխալ չէ, նրանք նկարագրում են մեկ սեսիայի տարբեր շերտեր։
Երեք հասցե, և մատյանի մեջ միայն մեկը
Շփոթմունքն առաջանում է երեք հասցեն մեկի մեջ միավորելուց։ Յուրաքանչյուրն ունի տարբեր սեփականատեր, ապրում է տարբեր վերնագրում և սերվերին հասնում է տարբեր ճանապարհով։
| Address | Who assigns it | Where it sits | Visible to the VPN server |
|---|---|---|---|
Device address, e.g. 192.168.1.24 | Your router via DHCP | Outer header, before translation | No, rewritten in place |
| Translated address and port | Router, ISP CGNAT, or both | Outer header, after translation | Yes, this is the tuple it logs |
Tunnel address, e.g. 10.8.0.6 | The VPN server itself | Inner header, after decapsulation | Yes, but it chose it |
Միայն միջին տողն է անհայտ միանալու պահին։ Սերվերը գրում է այն իր գործընկերների աղյուսակում, կարգավիճակի ֆայլում կամ հոսքի մատյանում՝ կախված դեմոնից. WireGuard-ը այն անվանում է վերջնակետ, OpenVPN-ի կարգավիճակի ֆայլը նշում է այն որպես Real Address, իսկ strongSwan-ը հայտնում է այն որպես IKE_SA-ի հեռավոր հոսթ։ Այդ արժեքը թարմացվում է ամեն անգամ, երբ փաթեթը գալիս է այլ աղբյուրից, ուստի այն փոխվում է առանց որևէ մեկի ինչ-որ բան վերագործարկելու։
Ներքևի տողն այն է, ինչ մարդիկ սխալմամբ կարդում են որպես ինքնության պահանջ։ Այն նշում է տեղ սերվերի կոնֆիգուրացիայում, ոչ թե մարդ, որովհետև սերվերն այն ընտրել է իր իսկ պահուստից։ Երկու օգտատեր կարող են տարբեր օրերին ստանալ նույն թունելի հասցեն, և մեկը կարող է ունենալ դրանցից երկուսը երկու սարքից։
Ինչու է մատյանում գրված թուպլը փոխվում, մինչ թունելը մնում է բաց
Հասցեների թարգմանությունը աղյուսակ է ժամաչափով, ոչ թե մշտական կապում։ Տնային երթուղիչը պահում է իր UDP քարտեզագրումը վերջին փաթեթից որոշ ժամանակ, օպերատորի դարպասը վերամշակում է պորտերը իր ժամանակացույցով, իսկ Wi-Fi-ից LTE անցնող հեռախոսը վերադառնում է բոլորովին այլ աղբյուրով։ Linux-ի conntrack-ի լռելյայն արժեքները այստեղ օգտակար չափանիշ են. nf_conntrack_udp_timeout-ը 30 վայրկյան է, իսկ հոսքային տարբերակը՝ 120, այնպես որ հանգիստ թունելը կարող է կորցնել քարտեզագրումը շատ ավելի վաղ, քան օգտատերը կնկատի։
Թունելը գոյատևում է, որովհետև արձանագրությունը վավերացնում է գործընկերոջը, ոչ թե հասցեն։ WireGuard-ը ձեռքսեղմումից հետո վիճակազուրկ է, ուստի ցանկացած վավերացված փաթեթ թարմացնում է պահված վերջնակետը, և վերակապումը բուժվում է հաջորդ փաթեթով, դրա համար էլ գոյություն ունի persistent-keepalive = 25-ը՝ քարտեզագրումը տաք պահելու համար անգործության ժամանակ։ OpenVPN-ի --float-ը նույն գործն է անում՝ թույլ տալով վավերացված հաճախորդին շարունակել նոր հասցեից և պորտից։ 2.4 և 2.5 տարբերակներում, որտեղ float-ը լռելյայն անջատված է, վերակապումը վերականգնում է սեսիան, և հաճախորդը նորից միանում է։
IPsec-ը հասնում է այնտեղ ավելի շատ շարժական մասերով։ IKEv2-ը նկատում է թարգմանությունը՝ համեմատելով աղբյուրի և նպատակակետի հեշերը NAT-ի հայտնաբերման բեռնվածքներում, անցնում է UDP 4500 ինկապսուլյացիայի և հետևում keepalive-ներին մինչև նոր թուպլը։ Երբ keepalive-ները արգելափակված են, SA-ն մնում է բաց միայն թղթի վրա, մինչ մի ուղղությամբ երթևեկությունը լուռ կանգ է առնում։
Ինչ կարող է սերվերը վերագրել, և ինչ՝ ոչ
Առասպելը, որն արժե սպանել, այն է, թե թարգմանությունը թաքցնում է ձեզ օպերատորից։ Այն փոխում է պիտակը, ոչ թե դիտարկումը։ Օպերատորի NAT-ի հետևում գտնվող դարպասը տեսնում է 100.64.0.0/10 տարածությունը կամ մեկ հանրային հասցե, որը կիսում են շատ բաժանորդներ, և այնուամենայնիվ կարող է հոսքը կապել վկայագրի սուբյեկտի, WireGuard-ի հանրային բանալու, հատկացված թունելի հասցեի, բայթային հաշվիչների և ժամանակային պատուհանի հետ։ Դրանցից ոչ մեկին ձեր LAN հասցեն պետք չէ։
Սահմանափակումները գնում են նաև հակառակ ուղղությամբ։ Մատյանի մեջ կիսված հասցեն ցույց է տալիս դարպասի, ոչ թե տնային տնտեսության. նույն թարգմանված հասցեից տարբեր պորտերով երկու սեսիաները տարբեր սարքեր են. նույն հասցեն երկու տարբեր օրերին կարող է լինել երկու անկապ բաժանորդ, եթե պորտը վերամշակվել է։ Սերվերը, որը գրանցում է միայն գործընկերների բանալիները, չի կարող դրանք կապել հաճախորդի հետ առանց հաշիվների տվյալների բազայի, իսկ սերվերը, որը գրանցում է միայն հասցեներ, չի կարող տարբերել նոթբուքը հեռախոսից նույն երթուղիչի հետևում։
Համեմատեք երկու ծայրերը՝ գուշակելու փոխարեն
Պարզելու համար, թե ինչ եղավ, գրավեք նույն կապը երկու ծայրերում նույն պահին և համեմատեք թուպլը, ոչ թե հասցեն։ Հաճախորդի վրա, ցանկացած թարգմանությունից առաջ.
ss -uapn 'dport = :51820'
ip -4 route get 203.0.113.10
wg show wg0 endpointsԱյնուհետև կարդացեք թարգմանության գրառումը երթուղիչի կամ CGNAT դարպասի վրա, և այն, ինչ ի վերջո հասնում է սերվերին.
conntrack -L -p udp --dport 51820
tcpdump -ni eth0 udp port 51820Երեք օրինաչափություն բացատրում են անհամապատասխանությունների մեծ մասը։ Սերվերի աղբյուր պորտը տարբերվում է տեղական պորտից, մինչ նպատակակետը համընկնում է. սովորական պորտի թարգմանություն։ Սերվերի աղբյուր հասցեն պատկանում է ISP բլոկի, որը ձերը չէ. առնվազն մեկ լրացուցիչ NAT շերտ։ Փաթեթները կանգ են առնում անգործության շրջանից հետո և շարունակվում նոր պորտով. քարտեզագրումը լրացել է, ոչ թե երթուղային խափանում։ Եթե ժամանակային նշանները մեկ-երկու վայրկյանից ավելի հեռու են, դուք համեմատում եք երկու տարբեր փորձ։
Որտեղ է տարբերությունը կոտրում ամեն ինչ
Սերվերի խափանումների նման ընդհատումները սովորաբար սկսվում են այստեղ։ Ձեր տնային հասցեին կապված մուտքի կանոնը ձախողվում է ISP-ի վարձակալության փոփոխությունից հետո։ Թարգմանված հասցեին համապատասխանող fail2ban կանոնն արգելափակում է այդ դարպասի հետևի բոլոր բաժանորդներին միանգամից։ Հաստատուն հեռավոր հասցեով կայք-կայք գործընկերը դադարում է թարմացնել բանալիները բջջային կապի փոփոխությունից հետո։ Թունելի արձանագրությունը կարգին էր. արտաքին թուպլի մասին ենթադրությունը՝ ոչ։
Նույն շփոթմունքը երևում է սերվերի կողմում։ Եթե VPN տուփն ինքն է NAT-ի հետևում, ձեզ պետք է պորտի փոխանցում և աշխատող փոխանցման ուղի. strongSwan-ի փոխանցման ուղեցույցը լուսաբանում է այդ դեպքը IPsec-ի համար։ Միայն մասնավոր հասցեով հասանելի սերվերը երբեք չի տեսնում իր հաճախորդների ներկայացրած թարգմանված թուպլը, և դա այլ խնդիր է, քան հաճախորդների թարգմանությունը։
Անցեք այս չորս ստուգումները հերթականությամբ և կանգ առեք առաջին ձախողվածի վրա.
- Գրավեք երկու ծայրերում միաժամանակ. հաստատեք, որ աղբյուր պորտը, նպատակակետ պորտը և ժամանակային նշանները համընկնում են։
- Սերվերի գործընկերների ցանկում կարդացեք այն հասցեն, որը նա հիմա պահում է, ոչ թե այն, ինչ դուք սպասում էիք։
- Ստուգեք conntrack կամ NAT աղյուսակը՝ գրառման և դրա մնացած կյանքի համար։
- Հաստատեք, որ հաճախորդի թունելի ինտերֆեյսի հասցեն համընկնում է սերվերի հատկացրածի հետ, ոչ թե LAN հասցեի։
Եթե երկու գրավումները համաձայն են թուպլի շուրջ, և թունելը դեռ ձախողվում է, թարգմանությունը ձեր խնդիրը չէ. անցեք ձեռքսեղմմանը և թունելի ներսի երթուղային աղյուսակին։