Որտեղ է տեղադրվում VPN-ի NAT-ը UFW-ի before.rules-ում և ինչպես փորձարկել այն

NAT կանոնը, որը աշխատում է shell-ում մուտքագրելիս, ձախողվում է before.rules-ում տեղադրվելիս, քանի որ այդ ֆայլը սկրիպտ չէ։ Այն վերականգնման ձևաչափի փաստաթուղթ է՝ աղյուսակների բաժիններով, շղթաների հայտարարություններով և յուրաքանչյուր աղյուսակի համար COMMIT նշիչով։ Սխալ տեղում գտնվող տողը կա՛մ ընդհատում է ամբողջ վերականգնումը, կա՛մ լուռ հեռացնում է կանոններ, որոնք դուք կարծում էիք, թե կան։ Ստորև ներկայացված ուղեցույցը տեղադրում է հատվածը այնտեղ, որտեղ շրջանակը սպասում է, և ապացուցում արդյունքը հաջորդ վերալոդումից առաջ։

Shell-ի հրամանը վերականգնման ֆայլ չէ

iptables -t nat-ով սկսվող տողը հրահանգ է iptables երկուական ֆայլին, մինչդեռ UFW-ի կարդացած ֆայլը ամբողջական կանոնների հավաքածուի նկարագրություն է։ Տարբերությունը կոսմետիկ չէ. վերականգնման ձևաչափը պետք է իմանա, թե որ աղյուսակում է, որ շղթաներն են գոյություն ունեն, և որտեղ է ավարտվում աղյուսակը։ Այդ փաստաթղթում տեղադրված հրամանը կա՛մ շարահյուսական սխալ է, կա՛մ, ավելի վատ, սխալ աղյուսակին կցված կանոն։ Շրջանակը բեռնում է այս ֆայլերը վերականգնման գործիքներով հենց այն պատճառով, որ դրանք հռչակագրային են, ոչ հաջորդական։

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

Տեղադրեք հատվածը գոյություն ունեցող աղյուսակի բաժնում

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

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT

Վերևի փուլը և ինտերֆեյսը ձեր արժեքների տեղապահներն են. կառուցվածքն այն մասն է, որ արժե պատճենել։ Եթե ֆայլն արդեն պարունակում է *nat բաժին, կանոնը ավելացրեք այդ բաժնի ներսում՝ երկրորդը բացելու փոխարեն, քանի որ ձևաչափը յուրաքանչյուր աղյուսակի համար մեկ COMMIT է սպասում, և նույն աղյուսակի համար երկու բաժինը վերանորոգում է, որը սպասում է տեղի ունենալուն։ Պահպանեք տարածման շղթաների սահմանումները անձեռնմխելի, ներառյալ նրանք, որ մատակարարը ավելացրել է իր ինտեգրման համար։ UFW շրջանակի ձեռնարկը փաստագրում է before, user և after ֆայլերը համապատասխան COMMIT-ի պահանջի հետ միասին։

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

Փորձարկեք թեկնածուին առանց կիրառելու

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

sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"

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

Ընտրեք տեղադրված backend-ին և հասցեների ընտանիքին համապատասխանող գործիք։ nft backend-ը համատեղելիության շերտով գործարկող հոսթը պահանջում է համապատասխան հրամանը, և IPv6 կանոնները բնակվում են բոլորովին այլ ֆայլում։

Առանձնացրեք փոխանցումը, NAT-ը և մուտքի քաղաքականությունը

Աղբյուրի թարգմանությունը լուծում է հասցեավորման խնդիր և ոչինչ չի տալիս։ Փոխանցումը առանձին թույլտվություն է, որը կառավարվում է sysctl-ով և զտիչ աղյուսակով, և հենց այն մոռանում են մարդիկ, երբ թունելը երթուղավորում է, բայց տրաֆիկ չի անցնում։ Մուտքի քաղաքականությունը երրորդ որոշումն է այն մասին, թե որ աղբյուրները կարող են հասնել որ ծառայություններին, և ոչ մի NAT կանոն այն չի արտահայտում։ Հենց այս երեքի առանձնացումն է, որ ձախողումը դարձնում է ախտորոշելի, այլ ոչ թե մեկ անորոշ ախտանիշ։

sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD

Կարդացեք այդ երեք ելքերը միասին, ոչ թե մեկ առ մեկ։ Առանց փոխանցման masquerade կանոնը ստեղծում է հաճախորդ, որը միանում է և ոչ մի տեղ չի հասնում, ինչը հաճախորդի կողմից ուղիղ նման է երթուղավորման խափանման և մարդկանց ուղարկում է սխալ ֆայլ։ Զտիչ աղյուսակը նաև այն տեղն է, որտեղ թաքնվում է չափից ավելի լայն accept-ը, ուստի այնտեղ գտնվելիս ստուգեք դրա լռելյայն քաղաքականությունը։

Ստուգեք վերալոդումը, մերժումը և VPN-ի կորուստը

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

sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

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

IPv4-ի NAT-ը ոչինչ չի ասում IPv6-ի մասին, ուստի նշեք նախատեսված ծածկույթը երկու ընտանիքների համար նույն նշումում, ինչ կանոնը։ Նպատակը համահունչ կառավարվող քաղաքականությունն է, և պատահաբար վերլուծված հատվածը դրա ապացույցը չէ։