Սերվերի IP-ի փոփոխությունից հետո SNAT կանոնը դեռ նշում է հինը

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

Միանալը և փոխանցումը ձախողվում են տարբեր տեղերում

Կապի հաստատումը կախված է այն վերջնակետից, որը հաճախորդներն արդեն գիտեն՝ հրապարակային հասցեն, դրա դիմացի պորտի փոխանցումը և ներսի լսողը։ Փոխանցված երթևեկությունը կախված է երկրորդ որոշումից, որն ընդունվում է այն բանից հետո, երբ փաթեթը մտնում է թունել, երբ հոսթը վերագրում է իր աղբյուրը, որպեսզի պատասխանները գտնեն վերադարձի ճանապարհը։

Հասցեի փոփոխությունը կոտրում է միայն երկրորդ որոշումը, և դրա համար ախտանիշը կարդացվում է որպես «միացված է, բայց ինտերնետ չկա»։ Սա նաև բացատրում է, թե ինչու հաճախորդի կողմի սովորական ստուգումները առողջ են երևում. ձեռքսեղմումը ավարտվում է, հաճախորդը հասցե է ստանում, և նույնիսկ սերվերի թունելի հասցեին ping-ը կարող է պատասխանել։ Ժամեր են վատնում հաճախորդի վրա մի խափանման պատճառով, որը ապրում է մյուս կողմում, դրա համար կանոնների աղյուսակը առաջին տեղն է, որտեղ պետք է նայել։

Խմբագրելուց առաջ կարդացեք կանոնը և դրա հաշվիչները

Թվարկեք թարգմանության կանոնները հաշվիչներով և համեմատեք կարգավորված աղբյուրը այն հասցեների հետ, որոնք հոսթն իրականում ունի։ Մեռած հասցեի վերագրված կանոնը սովորաբար ցույց է տալիս երթևեկություն ներսի ուղղությամբ, որովհետև փաթեթները հասնում են դրան և թարգմանվում, իսկ վերադարձի ուղղությամբ՝ ոչինչ։

sudo iptables -t nat -L POSTROUTING -n -v --line-numbers
ip -4 addr show

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

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

Փոխարինեք աղբյուրը կամ դադարեք մեկը նշելուց

Երբ հոսթն ունի կայուն հասցե, փոխարինեք կանոնը իր տեղում, այլ ոչ թե ավելացնեք ևս մեկը։ Կանոնի համարով փոխարինումը պահպանում է այն հերթականությունը, որից կախված է շղթայի մնացած մասը։

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 10.151.0.40

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

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -o eth0 -j MASQUERADE

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

Փոխարինումը սխալ անելու երկու եղանակ

Լողավազանը սերվերի թունելի հասցեին թարգմանելը՝ նրա LAN հասցեի փոխարեն, պատասխաններն ուղիղ հետ է ուղարկում թունել, որտեղ դրանք երթուղվում են դեպի հաճախորդ, որը երբեք չի խնդրել դրանք։ Կապը կանգ է առնում այնպես, որ նման է երթուղային օղակի, որովհետև այդպիսին է։

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

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

Ներս եկող ծառայություններին պետք է հակառակ թարգմանությունը

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

sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 10.9.8.2:8080

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