Տնային սերվերի հրապարակում VPS-ի միջոցով, երբ CGNAT-ը արգելափակում է պորտերը

Ուղին բրաուզերից մինչև տնային մեքենա՝ ապացուցիր, որ գիծը CGNAT-ի հետևում է, DNS-ը ուղղիր VPS-ին, արա DNAT մեկ պորտի վրա, ուղղիր վերադարձի ուղին և ստուգիր դրսից։

Ես սկսեցի դրսից, ինչպես կաներ օգտատերը՝ անունը մուտքագրեցի բջջային ինտերնետով հեռախոսի բրաուզերում և տեսա, թե ինչպես կապը կախված մնաց մինչև ժամանակի սպառումը։ Անունը լուծվում էր, ուրեմն DNS-ը կարգին էր։ Տան երթուղիչի պորտերի վերահասցեավորման էջը նույնպես փակուղի էր, քանի որ դրա WAN հասցեն ցույց էր տալիս 100.64.31.42, և դա այն հասցեն չէ, ուր մատակարարը ինձ ուղղորդում է ինտերնետից։ Այս թիվը բացատրում է ամբողջ խափանումը. գիծը գտնվում է carrier-grade NAT-ի հետևում, ուստի թունելի իմ կողմի հանրային հասցեն պատկանում է մատակարարին։ Հետևյալը այն ուղին է, որն անցա այդ կախված ներդիրից մինչև պատասխանող ծառայություն։

Սկսիր հաճախորդից և գնա ներս

Նախքան որևէ կանոն փոխելը՝ ապացուցիր, թե որտեղ է կանգնում շղթան։ Նոութբուքի վրա գործարկեցի dig +short files.example.net և հետ ստացա VPS-ի հասցեն, ինչը բացառեց իմ մեքենայի հնացած DNS-ը։ Այնուհետև curl -v --connect-timeout 5 files.example.net:5022 ժամանակի սպառման ենթարկվեց՝ մերժվելու փոխարեն։ Այս տարբերությունը կարևոր է. ժամանակի սպառումը սովորաբար նշանակում է, որ փաթեթները ճանապարհին դեն են նետվում, մինչդեռ մերժումը նշանակում է, որ ինչ-որ բան պատասխանել է և ասել ոչ։

Ներս հաջորդ քայլը հենց VPS-ն էր։ ss -ltnp ոչինչ չցուցադրեց, ինչ լսեր 5022-ում, ինչը սպասելի էր DNAT կանոնի առաջացումից առաջ։ Նույն մեքենայի վրա wg show (կամ OpenVPN-ի համար ip -br a show tun0) հաստատեց, որ տան peer-ը աշխատում է և ունի թարմ handshake։ Եթե peer-ը չի աշխատում, ոչ մի NAT կանոն չի օգնի, իսկ տան երթուղիչի VPN էջի կանաչ լույսը ոչինչ չի նշանակում։

Հաստատիր, որ տան գիծը իրոք CGNAT-ի հետևում է

Համեմատիր երթուղիչի WAN միջերեսում հաղորդած հասցեն այն բանի հետ, ինչ տեսնում է արտաքին ծառայությունը։ Ամեն ինչ 100.64.0.0/10-ում, այսինքն 100.64.x.x-ից 100.127.x.x, RFC 6598-ի ընդհանուր հասցեների միջակայքն է և ինտերնետից անհասանելի է։ Նույն եզրակացությանը կգաս, երբ երթուղիչը պնդում է, որ սովորական մասնավոր հասցե ունի, իսկ հանրային հարցումը վերադարձնում է ինչ-որ անկապ բան։ CGNAT գիծը կարող է ունենալ նաև հանրային հասցե, որը գործում է միայն մինչև հաջորդ lease-ը, այնպես որ պորտի վերահասցեավորումը թվում է, թե մեկ ժամ աշխատում է, ապա լուռ մահանում։

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

Ուղղիր անունը VPS-ի հասցեին

DNS-ը տրաֆիկ չի փոխանցում, ուստի ծառայության A գրառումը պետք է պարունակի VPS-ի հանրային հասցեն։ 192.168.1.20-ին ուղղված A գրառումը օգտակար լուծվում է միայն VPN-ի ներսում գտնվող հաճախորդների համար. ինտերնետից այն լուծվում է հասցեի, որը ոչ ոք չի կարող ուղղորդել։ VPS-ի սեփական ադմինիստրատիվ մուտքի համար առանձին անուն եմ պահում, որպեսզի երբեք չշփոթեմ, թե որ հոսթին է վերաբերում գրառումը։

Եթե և՛ VPS-ը, և՛ տան մեքենան սպասարկում են HTTP, յուրաքանչյուրին տուր իր անունը և թող VPS-ը որոշի, թե ով է պատասխանում։ Դրանք մեկ անվան մեջ միավորելը և հույսը, որ պրոքսին կընտրի ճիշտ backend-ը, հենց այն է, ինչով ամբողջ կեսօր սխալ հոսթում վրիպակ ես փնտրում։

Մեկ պորտ DNAT-ով, SSH-ը մնում է 22-ում

Ուղիղ տարբերակը նպատակակետային NAT-ն է VPS-ի վրա։ Միացրու forwarding-ը աշխատող միջուկի համար և կանոնում պահիր տան սերվերի թունելի հասցեն, ոչ թե նրա LAN հասցեն։

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -p tcp -d 198.51.100.10 --dport 5022 -j DNAT --to-destination 10.8.0.2

Թող SSH-ը դեպի հենց VPS-ը մնա 22-ում, իսկ մեկ այլ պորտ, օրինակ 5022-ը, ուղղորդիր տան մեքենային։ Եթե 22-ը ուղղորդես անջատված մեքենային, կկորցնես միակ ուղին, որը կարող էր ուղղել այն։ Նույն տրամաբանությունը վերաբերում է պրոքսիին. պահիր VPS-ի կառավարման պորտը relay կանոններից դուրս։

Կանոնները դարձրու մշտական, հենց որ աշխատեն։ Debian-ում կամ Ubuntu-ում apt install iptables-persistent և ապա netfilter-persistent save դրանք գրում են /etc/iptables/rules.v4 ֆայլում։ firewalld ունեցող հոսթում համարժեքը գոտում մշտական պորտի ուղղորդումն է, որը կիրառվելուց առաջ պահանջում է firewall-cmd --reload։ Միայն հիշողության մեջ ապրող կանոնները անհետանում են մատակարարի առաջին սպասարկման վերագործարկման ժամանակ, սովորաբար վատ ժամին։

Ուղղիր վերադարձի ուղին կամ խուսափիր դրա կարիքից

DNAT-ը վերագրում է միայն նպատակակետը։ Տան սերվերը կապը տեսնում է սկզբնական հաճախորդի հասցեից, և եթե նրա լռելյայն ուղին ուղղված է տան երթուղիչին, պատասխանը դուրս է գալիս տան WAN-ով, որտեղ մատակարարի թարգմանիչը գցում է այն։ Այդ ասիմետրիան երկրորդ խափանումն էր, որին հանդիպեցի այն բանից հետո, երբ DNAT կանոնը լրիվ ճիշտ էր թվում։

Երկու ուղղում աշխատում է։ Տան մեքենային տուր քաղաքականության ուղի, որպեսզի թունելից եկող տրաֆիկը վերադառնա թունելով։

ip rule add from 10.8.0.2 table 100
ip route add default dev wg0 table 100

Կամ թող VPS-ը վերագրի աղբյուրը, որպեսզի պատասխանն ունենա հասանելի հասցե, և conntrack-ը ելքի վրա շրջի այն։

iptables -t nat -A POSTROUTING -d 10.8.0.2 -p tcp --dport 5022 -j SNAT --to-source 10.8.0.1

SNAT տարբերակը թաքցնում է իրական հաճախորդի հասցեն տան սերվերից, ուստի հավելվածի մատյանները peer-ի տեղում ցույց են տալիս 10.8.0.1։ Փոխանցիր սկզբնական հասցեն հավելվածի մակարդակում կամ ընդունիր հաճախորդով պայմանավորված մատյանների կորուստը, բայց որոշիր դա գիտակցաբար, փոխանակ միջադեպի ընթացքում հայտնաբերես։

Ստուգիր ամբողջ ուղին դրսից

Ստուգիր ցանցից, որը ոչ VPS-ն է, ոչ էլ տունը՝ հեռախոս բջջային ինտերնետով կամ էժան shell այլ տեղ։ nc -vz files.example.net 5022 պետք է հաղորդի հաջող կապի մասին, իսկ openssl s_client -connect files.example.net:443 -servername files.example.net պետք է ցույց տա վկայագիրը հանրային անվան համար։ Ապա ստուգիր մատակարարի անվտանգության խումբը կամ ամպային firewall-ը։ DNAT կանոնը, որը երբեք փաթեթ չի տեսնում, սովորաբար արգելափակվում է հոսթից մեկ շերտ վերև։

Վերջապես որոշիր, թե ինչ է լինում, երբ թունելն ընկնում է։ DNAT կանոնը շարունակում է ընդունել կապեր և լուռ լցնում դրանք մեռած թունելի մեջ, ինչը ճիշտ նման է կոտրված ծառայության։ VPS-ի վրա առողջության ստուգումը, որը մերժում է պորտը քանի դեռ peer-ը չի աշխատում, արժե մի քանի տող և խնայում է մեկ ժամ գուշակություն։ Դրանից հետո դադարիր կանոնները խմբագրել և մեկ օր դիտարկիր նախքան վստահելը։

Առնչվող հոդվածներ