Հրապարակեք VPN հաճախորդի պորտը CGNAT-ի հետևից՝ ստուգաթերթ

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

Հաստատեք, որ սերվերը ընդհանրապես կփոխանցի

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

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1

Այն աշխատող միջուկում դնելը նույնը չէ, ինչ վերագործարկման ընթացքում դնելը։ Գրեք net.ipv4.ip_forward=1-ը /etc/sysctl.d/-ի տակ գտնվող ֆայլում, գործարկեք sysctl --system-ը, ապա կարդացեք արժեքը հետ, փոխարենը վստահելու, որ ֆայլը վերցվել է։ Կոնտեյները, որը կառավարում է իր ցանցային անվանատարածքը, կարիք ունի նույն արժեքին այդ տարածքի ներսում, ոչ միայն հոսթի վրա։

Եթե հետընթեր ընթերցումը դեռ զրո է, կանգ առեք այստեղ։ Ներքևում ոչինչ չի աշխատի։

Ամրացրեք թունելի հասցեն նախքան որևէ կանոն կհղվի դրան

Ֆոնդը հասցեներ է բաժանում միացման հերթականությամբ, այնպես որ այսօրվա վարձակալության համար գրված կանոնը հաջորդ շաբաթ կարող է լուռ մատնանշել այլ հաճախորդի։ Կապեք հասցեն վկայագրի ինքնությանը, ոչ թե ժամանման հերթականությանը։

client-config-dir /etc/openvpn/ccd
ifconfig-push 10.77.0.14 10.77.0.13

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

Եթե հասցեն փոխվում է նոր միացումից հետո, կանգ առեք։ Շարժվող թիրախին հետևող NAT կանոնը պարբերաբար կձախողվի և ձեզ ոչինչ չի սովորեցնի։

Թարգմանեք երկու ուղղությամբ

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

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 29443 -j DNAT --to-destination 10.77.0.14:29443
iptables -t nat -A POSTROUTING -d 10.77.0.14 -p tcp --dport 29443 -j SNAT --to-source 10.77.0.13

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

Կարդացեք երկու կանոնները հետ iptables -t nat -S-ով և հաստատեք, որ միջերեսի անունը հենց այն է, որը կրում է հանրային հասցեն։ Այն հոսթի վրա, որը արդեն զտում է nftables-ով, թարգմանությունը գրեք համապատասխան հասցեների ընտանիքի nftables NAT շղթայում, գործիքները խառնելու փոխարեն։

Թողեք զտիչ աղյուսակը անցնի

NAT աղյուսակները վերաշարադրում են վերնագրերը, նրանք թույլտվություն չեն տալիս։ Լռելյայն DROP քաղաքականության դեպքում փոխանցվող հոսքը կարիք ունի իր սեփական թույլտվությանը, գումարած վերադարձի ուղղությունը, որը քաղաքականությունների մեծ մասն արդեն ծածկում է established,related կանոնով։

iptables -A FORWARD -i eth0 -o tun0 -p tcp --dport 29443 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Ստուգեք FORWARD շղթայի քաղաքականությունը նախքան որևէ բան ավելացնելը, որովհետև վաղ DROP-ի հերթականությունը որոշում է, թե արդյոք ձեր կանոնը երբևէ հաշվի կառնվի։ Այն հոսթի վրա, որի զտումը ապրում է nftables-ում, ավելացրեք համարժեք կանոնը inet աղյուսակի forward կեռիկին և հաստատեք, որ հիմնական շղթան իսկապես տեսնում է փոխանցվող տրաֆիկը, ոչ միայն տեղական մուտքը։ Եթե նոր կանոնի փաթեթների հաշվիչը մնում է զրոյի վրա, մինչ NAT հաշվիչները բարձրանում են, փաթեթը մերժվում է ձեր կանոնից առաջ։ Դա ազդանշան է կարդալու շղթաների հերթականությունը, ոչ թե ավելացնելու նույն կանոնի երկրորդ օրինակը։

Ապացուցեք դա արտաքին ցանցից

Փորձարկեք չկապված ցանցից։ Նույն LAN-ի մեկ այլ մեքենայից ստուգումը կարող է անցնել hairpin NAT-ի աջակցությամբ և երբեք չփորձարկի այն ուղին, որն օգտագործում է հեռավոր հաճախորդը, այնպես որ այնտեղ կանաչ արդյունքը ապացուցում է սխալ բան։

tcpdump -ni any port 29443
conntrack -L | grep 29443

Գործարկեք որսումը սերվերի և հաճախորդի վրա միաժամանակ։ Սերվերի որսումը ցույց է տալիս, թե արդյոք թարգմանված փաթեթը դուրս է գալիս դեպի թունել, հաճախորդի որսումը ցույց է տալիս, թե արդյոք հարցումը հասնում է և ուր է հասցեագրված պատասխանը։ conntrack -L-ում թարգմանության գրառումը ապացուցում է, որ կանոնը համընկել է, իսկ դրա բացակայությունը ապացուցում է, որ փաթեթը երբեք չի հասել NAT շղթային։

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