Երկու VPN հաճախորդ, երկու հանրային հասցե՝ համապատասխանեցրեք SNAT-ը
SNAT-ը ըստ աղբյուրի կարող է ընտրել հանրային հասցե, բայց միայն այնքան ժամանակ, քանի դեռ դարպասը դեռ կարող է տարբերել հաճախորդներին։ Ստուգեք մնացած աղբյուրը՝ նախքան կանոնը գրելը։
Երկու VPN հաճախորդ կարող են դուրս գալ երկու տարբեր հանրային IPv4 հասցեներով, և դա անող կանոնը կարճ է, քան շատերն են սպասում։ Այն աշխատացնում է ոչ թե iptables-ի շարահյուսությունը, այլ փաթեթի վիճակը, երբ այն հասնում է ելքի շղթային՝ այնտեղի աղբյուրի հասցեն դեռ պետք է տարբերի հաճախորդներին։ Եթե ավելի վաղ masquerade-ը երկուսին արդեն միավորել է մեկ հասցեի վրա, ոչ մի հաճախորդի կանոն չի կարող վերականգնել այդ տարբերությունը։ Նախ լուծեք այս հարցը, ապա գրեք թարգմանությունը։
Որ ինքնությունն է հասնում դարպասին
Կանոնը համապատասխանում է փաթեթի աղբյուրի հասցեին, ոչ VPN օգտանվանը և ոչ էլ այն անվանը, որը ցույց է տալիս հաճախորդի հավելվածը։ Ամեն ինչ, ինչ փաթեթը թարգմանում է ավելի վաղ ճանապարհին, որոշում է, թե ձեր կանոնը դեռ ինչ կարող է տեսնել։ Գործարկեք nat աղյուսակը հերթականությամբ և գտեք այն կետը, որտեղ աղբյուրը դեռ յուրաքանչյուր հաճախորդի համար առանձին է։
iptables -t nat -S POSTROUTING
Կարդացեք այդ ցանկը վերևից։ Վերևին մոտ masquerade կանոնը վերագրում է աղբյուրը յուրաքանչյուր համապատասխան հոսքի համար, և դրանից հետո տեղադրված հաճախորդային գրառումները համապատասխանում են հասցեի, որ այլևս գոյություն չունի։ Երբ երկու LAN սարքեր կիսում են մեկ թունել և ժամանում որպես մեկ ներքին հասցե, դիզայնը պետք է փոխվի նախքան firewall-ը դա կանի՝ պահեք նրանց աղբյուրի միջակայքերը առանձին կամ յուրաքանչյուրին տվեք իր ներքին հասցեն։
Կապեք ներքին հասցեի հատկացումը նույնականացված հաճախորդի հետ։ Այդ հասցեն մեկ այլ սարքի հանձնելը հանձնում է նաև ելքի քաղաքականությունը, և աղբյուրի թարգմանությունը ինքնին ինքնության ապացույց չէ։
Թարգմանությունը չի կարող հասցե հորինել
Յուրաքանչյուր հանրային հասցե պետք է հատկացվի կամ երթուղվի այս ելքի կետին, և պատասխանները պետք է գտնեն դեպի այն վերադարձի ճանապարհը։ Կանոնը, որն ուղարկում է երթևեկություն այնպիսի հասցեից, ուր ոչ ոք հետ չի երթուղում, հեռավոր ծայրում թողնվում է կամ պատասխանվում է հոսթի, որը երբեք չի խնդրել այն։ Ամպային մատակարարի օրինակի հանրային հասցեն սովորաբար թարգմանվում է մասնավոր ինտերֆեյսի հասցեի նախքան փաթեթի դուրս գալը, ուստի SNAT աղբյուրը պետք է լինի այն հասցեն, որը մատակարարը կընդունի, ոչ թե այն արժեքը, որը ցույց է տալիս կոնսոլը։ Կարդացեք մատակարարի հասցեների մոդելը և հետևեք դրան՝ փոխարենը չպատճենելով հանրային արժեքը յուրաքանչյուր փաթեթի մեջ։
Գործնականում դա նշանակում է ստուգել երթուղված նախածանցը մատակարարի կոնսոլում նախքան firewall-ին դիպչելը, և օգտագործել մասնավոր ինտերֆեյսի հասցեն որպես թարգմանության աղբյուր, երբ քարտեզագրումը մեկ առ մեկ է։ Ստորև բերված օրինակներում օգտագործված հասցեները վերցված են փաստաթղթային միջակայքերից, ուստի առաջինը, ինչ պետք է փոխարինվի, հենց հասցեի տեքստն է։
Տեղադրեք ընդհանուր masquerade-ից առաջ
Հաստատեք ելքի ինտերֆեյսը և ընթացիկ շղթան նախքան որևէ բան ավելացնելը։ Առաջինը որոշում է, թե որ փաթեթների հետ կարող է համապատասխանել կանոնը, իսկ երկրորդը ցույց է տալիս, թե ինչ է արդեն կանգնած դրա առջև։
ip -4 route show default
iptables -t nat -L POSTROUTING -n -v --line-numbers
Առաջին հրամանը նշում է ինտերֆեյսը, որով ինտերնետ ուղևորվող փաթեթն իրականում դուրս է գալիս։ Երկրորդը տպում է շղթան տողերի համարներով։ Ընդհանուր masquerade գրառումը այն տողն է, որից վերև պետք է մնալ։
iptables -t nat -I POSTROUTING 1 -s 10.88.4.20/32 -o ens3 -j SNAT --to-source 198.51.100.77
iptables -t nat -I POSTROUTING 1 -s 10.88.4.21/32 -o ens3 -j SNAT --to-source 198.51.100.78
Վերևի երկու կանոնները համապատասխանում են մեկական ներքին հասցեի, սահմանափակում են համապատասխանությունը ելքի ինտերֆեյսով և բացահայտ սահմանում աղբյուրը։ Տեղադրեք, ոչ թե ավելացրեք. դիրք 1-ում դրանք գնահատվում են masquerade տողից առաջ։ Երկուսի միջև հերթականությունը նշանակություն չունի, քանի որ նրանց աղբյուրները տարբեր են։ Փոխարինեք ens3-ը նրանով, ինչ հաղորդել է երթուղու հրամանը, և հեռու պահեք այլ firewall կառավարիչներին նույն կեռիկներից, քանի որ երկու գործիքների կողմից մեկ աղյուսակ գրելը սովորական պատճառն է, թե ինչու ճիշտ կանոնը ազդեցություն չի ունենում։
Ապացուցեք աղբյուրը նոր հոսքով
Stateful NAT-ը կապում է թարգմանություն, երբ հոսքը սկսվում է, և վերօգտագործում է այն հետագա փաթեթների համար, ուստի փոփոխությունից առաջ բացված սեսիան պահպանում է իր հին աղբյուրը փոփոխությունից հետո։ Միայն նոր սկսված կապն է ապացուցում կանոնը։
conntrack -L -s 10.88.4.20 -p tcp --dport 443
Կարդացեք այդ գրառման պատասխանի ուղղությունը. դրա նպատակակետը հասցեն է, որը հեռավոր ծայրը տեսնում է որպես աղբյուր։ Համեմատեք այն ձեր նախատեսած հանրային հասցեի հետ, և հին հասցեն կրող գրառումը համարեք շատ վաղ սկսված հոսքի ապացույց, ոչ թե կոտրված կանոնի։ Խնդրեք հաճախորդին նոր կապ բացել, ապա կրկնեք հարցումը։ Ամբողջ հետագծման աղյուսակը դատարկելը թեստը պարտադրելու համար ընդհատում է դարպասի մյուս բոլոր սեսիաները։
Թարգմանությունը դեռ չի ընտրում երթուղին, չի թողնում հոսքը զտիչով և չի հրապարակում մուտքային ծառայություն։ Սխալ երթուղին և բացակայող թույլտվության կանոնը շարունակում են ձախողվել նույնիսկ կատարյալ SNAT կանոնից հետո։ Ստուգեք նաև IPv6-ը և ցանկացած երկրորդական ելքի ուղի, ապա գրանցեք ներքին-հանրային զույգերը firewall-ի փաստաթղթերում, որպեսզի հաջորդ փոփոխությունը սկսվի քարտեզագրումից, ոչ թե կանոնի տեքստից։