Հասնել հեռավոր /24-ին թունելով՝ NETMAP, DNAT, թե՞ երթուղի։
Քարտեզագրեք ամբողջ նախածանցը NETMAP-ով, ավելացրեք DNAT կանոններ յուրաքանչյուր հոսթի համար կամ երթուղավորեք իրական միջակայքը, և որոշեք՝ հիմնվելով այն բանի վրա, թե ինչ պետք է տեսնի հեռավոր կողմը և ով կարող է սկսել երթևեկությունը։
Թունելի վերջնակետի հետևում գտնվող ենթացանցին կարելի է հասնել երեք եղանակով, և մեկ րոպե փաստեր հավաքելը սովորաբար երկուսին բացառում է։ Փաստերն են՝ արդյոք այնտեղի սերվերները պետք է տարբերեն օգտատերերին, արդյոք այնտեղից ինչ-որ մեկը երբևէ կզանգահարի ձեր միջակայքին, և ով կարող է խմբագրել հեռավոր ծայրի երթուղիչը։ Պատասխանեք այս երեքին, և դիզայնն ինքն իրեն կընտրվի։ Մնացածը ենթադրում է, որ դուք եք կառավարում վերջնակետը և կարող եք խմբագրել դրա ֆայրվոլը։
Երեք տարբերակ, և թե ինչ է իրականում փոխում յուրաքանչյուրը
Նախածանցի քարտեզագրումը, յուրաքանչյուր հոսթի DNAT-ը և երթուղավորված նախածանցը բոլորն էլ փաթեթները տեղափոխում են նույն երկու միջակայքերի միջև, բայց փոխում են տարբեր բաներ։ Քարտեզագրումը հնարում է alias-միջակայք և թռիչքի ընթացքում թվաբանորեն վերագրում հասցեները։ Յուրաքանչյուր հոսթի կանոնները նույնպես վերագրում են, միայն թե յուրաքանչյուր նպատակակետ ձեռքով է անվանվում։ Երթուղավորված նախածանցը ոչինչ չի վերագրում. փաթեթները պահպանում են իրական հասցեները, և երկու ծայրերը համաձայն են, թե որտեղ են ապրում այդ հասցեները։
| What the far side needs | Prefix mapping | Per-host DNAT | Routed prefix |
|---|---|---|---|
| Users visible to its logs | Only without source NAT | Same condition | Yes, unchanged |
| To start a connection toward you | No, alias is local | No, same reason | Yes, both ends route |
| To absorb a new host | Yes, arithmetic only | No, one rule per address | Yes, it simply routes |
| To require no config change | Yes, with source NAT | Yes, same condition | No, it needs a route back |
Վերացումը սկսեք հեռավոր կողմից, որտեղ սահմանափակումները ամենադժվարն են փոխել։ Եթե այնտեղի սերվերը գրում է հաճախորդների հասցեները մատյաններում, ստուգում է դրանք թույլատրվածների ցանկով կամ հանձնում է մեկ այլ համակարգի, աղբյուրի թարգմանությունը ոչնչացնում է նրա միակ նույնացուցիչը։ Եթե հեռավոր կողմը նույնպես պետք է զանգահարի, թարգմանությունը լրիվ դուրս է մնում, որովհետև այնտեղ ոչ ոք չգիտի, որ alias-ը գոյություն ունի։ Միայն այն ժամանակ, երբ հեռավոր կողմը պարզապես պատասխանում է հարցումներին, ավելի էժան տարբերակները դառնում են անվտանգ։
Նախածանցների զույգեր, և ինչու չափերը պետք է համընկնեն
NETMAP-ը nat աղյուսակի թիրախ է, որն աշխատում է նույն երկարության նախածանցների զույգի վրա։ Ներսում հասցեով աղյուսակ չունի. այն հեռացնում է նախածանցը, պահում է հոսթի բիթերը և նորից կցում դրանք նոր նախածանցին, դրա համար /24-ը քարտեզագրվում է /24-ի վրա և երբեք /25-ի։ Դիրքը որոշում է ուղղությունը. նպատակակետի համընկնումը PREROUTING-ում վերագրում է, թե ուր է գնում փաթեթը, իսկ աղբյուրի համընկնումը POSTROUTING-ում՝ թե որտեղից է այն եկել։
192.168.2.17 հոսթը ձեր հաճախորդներին երևում է որպես 10.50.1.17, և վերջին օկտետը զարդարանք չէ՝ այն նույն թիվն է երկու կողմերում։ Վաղը ավելացրեք հոսթ 192.168.2.40-ում, և նրա alias-ը կլինի 10.50.1.40՝ առանց խմբագրելու որևէ կանոն։
Հաճախորդներին դեռ պետք է երթուղի alias-միջակայքի համար, որը ցույց է տալիս ձեր արկղին, եթե alias-ը չի ընկնում ենթացանցի մեջ, որին նրանք արդեն հասնում են։ Հատույթին պետք չէ երթուղի alias-ի համար, քանի որ նպատակակետի թարգմանությունը կատարվում է PREROUTING-ում՝ երթուղու որոնումից առաջ։ Փոխանցումը նույնպես պետք է միացված լինի, այլապես միջուկը փաթեթը գցում է վերագրումից հետո։ Ստորև բերված երեք հրամանները Debian ոճի հատույթի ամբողջ կարգավորումն են՝ հաճախորդները br0-ում, alias-ը 10.50.1.0/24-ում և թունելը tun0-ում։
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i br0 -d 10.50.1.0/24 -j NETMAP --to 192.168.2.0/24
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADEՊատասխանը պետք է ինքնուրույն գտնի վերադարձի ճանապարհը
Նպատակակետի վերագրումը միայն որոշում է, թե ուր կհանձնվի փաթեթը։ Հեռավոր կողմի սերվերը դեռ պետք է պատասխանի հասցեի, որին կարող է հասնել, և դա կազմակերպելու երկու եղանակ կա։ Թարգմանեք աղբյուրը, որպեսզի պատասխանները վերադառնան ձեր արկղին, կամ թողեք աղբյուրը հանգիստ և հեռավոր կողմին տվեք երթուղի հաճախորդների միջակայքի համար։
Ելքի վրա masquerade-ը ավելի կարճ ճանապարհն է. մեկ կանոն POSTROUTING-ում, և հեռավոր կողմը տեսնում է ձեր թունելի հասցեն, ուստի իր երթուղու կարիքը չունի։ Գինն այն է, որ բոլոր օգտատերերը միաձուլվում են մեկ հասցեի, և յուրաքանչյուր օգտատիրոջ մատյանները դադարում են իմաստ ունենալ։ Աղբյուրը անձեռնմխելի թողնելը պահպանում է այդ տեղեկությունը, բայց այդ դեպքում հեռավոր վայրը պետք է հաճախորդների միջակայքի պատասխանները հետ ուղարկի թունելով։ OpenVPN սերվերի վրա դա ուղարկված push "route 10.50.9.0 255.255.255.0" է, գումարած՝ route 192.168.2.0 255.255.255.0 տող։
Թանկ սխալը յուրաքանչյուրից կեսն անելն է։ Եթե masquerade եք անում երթևեկության մի մասի համար, մինչ հեռավոր կողմը նույնպես վերադարձի երթուղի է կրում այլ երթևեկության համար, պատասխանները գալիս են ինտերֆեյս, որտեղ կապի հետևման գրառումը երբեք չէր տեսել։ Հաճախորդը ժամանակի սպառում է հաղորդում այն հարցման համար, որը սերվերը գրանցել էր որպես սպասարկված։ Հոսքի երկու ուղղություններն էլ պետք է անցնեն նույն netfilter օրինակով՝ մեկ հատույթ թարգմանում է, ոչ թե երկու ֆայրվոլ հաջորդաբար։
conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -nԿարդացեք գրառումը երկու ուղղությամբ. սկզբնական tuple-ը պահում է ձեր alias-ը նպատակակետում, իսկ պատասխանի tuple-ը կրում է իրական հասցեն։ Եթե պատասխանի tuple-ը բացակայում է, խնդիրը վերադարձի ճանապարհն է, ոչ թե կանոնը։ Եթե PREROUTING-ի հաշվիչները երբեք չշարժվեցին, փաթեթը երբեք չհասավ այդ կեռին։
Բախումներ և առաջինը կատարվող որոնումը
Երկու տարբեր միջակայքեր կարող են բախվել, և երկու խափանումներն էլ նման են կոտրված թունելի, ոչ թե վատ կանոնի։ Ձեր հնարած alias-ը պետք է չօգտագործված լինի ամբողջ ճանապարհին, և հեռավոր կողմի իրական միջակայքը չպետք է արդեն գոյություն ունենա ձեր ցանցում։ Կրկնօրինակը ստեղծում է ընդհատվող երթևեկություն դեպի սխալ հոսթ, ինչն ավելի դժվար է ախտորոշել, քան մերժված կապը։ Հարցրեք երթուղային աղյուսակին՝ նախքան կանոն ավելացնելը։
Հատույթի վրա, ip route get 192.168.2.17 պետք է նշի թունելի սարքը. տեղական կամուրջը նշանակում է, որ հեռավոր միջակայքը ստվերված է, և ոչ մի nat կանոն այն չի վերականգնի։ Եթե ձեր սեփական ցանցն արդեն օգտագործում է 192.168.2.0/24, վերահամարակալեք հեռավոր վայրը՝ բախման վրա քարտեզագրում կուտակելու փոխարեն։
Փորձարկել իրական հաճախորդից, ապա պահպանել
Փորձարկեք մեքենայից, որն իսկապես կօգտագործի alias-ը, ոչ թե հատույթից, որովհետև տեղում ստեղծված երթևեկությունը երբեք նույն կերպ չի անցնում PREROUTING-ով։ Բացեք կապ դեպի alias ունեցող մեկ հոսթ և դիտեք, թե ինչպես հաշվիչներն ու conntrack գրառումը միասին են հայտնվում, ապա փակեք այն և հաստատեք, որ գրառումը հեռանում է։ Հնացած գրառումը ցույց է տալիս կիսաբաց կապ, ինչը սովորաբար նշանակում է, որ պատասխանը երբեք չի վերադարձել։
curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17Երկու կամ երեք հաջող կապեր ապացուցում են թվաբանությունը, բայց ոչինչ չեն ասում կայունության կամ հաջորդ ինժեների մասին։ Պահեք կանոնները այնտեղ, որտեղ դրանք կարդում է բեռնարկման գործընթացը, ինչը Debian-ում և Ubuntu-ում նշանակում է iptables-save > /etc/iptables/rules.v4՝ միացված netfilter-persistent-ով։ Վերագործարկման ժամանակ անհետացող քարտեզագրումն ավելի վատ է, քան ընդհանրապես չլինելը, որովհետև խափանումը գալիս է առանց վերջին փոփոխության, որին կարելի է մեղադրել։
Կանոնների կողքին թողեք գրառում՝ alias-միջակայքը, իրական միջակայքը, զույգի պատճառը և թե որ կողմը կարող է սկսել։ Այդ գրառումը տարանջատում է դիզայնը կանոնների կույտից, որը ոչ ոք չի համարձակվում ջնջել։ Այն նաև լուծում է ավելի ուշ առաջացող հարցը, երբ հեռավոր վայրն ավելացնում է հոսթ, և հասցե, որը ոչ ոք չի կարգավորել, արդեն պատասխանում է։ Եթե գրառումն ասում է, որ հեռավոր կողմին վերադարձի երթուղի է պետք, հաջորդ մարդը գիտի, որ masquerade-ի կանոնը հեռացնելը կկտրի կապը։ Այստեղ փաստաթղթավորումը էժան է. NAT-ից կախվածությունը գիշերվա երեքին նորից հայտնաբերելը՝ ոչ։