Պե՞տք է արդյոք SNAT կիրառել դեպի VPN ենթացանց պորտի փոխանցման վրա։

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

Ինչու պատասխանը այլ ճանապարհ է ընտրում

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

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

Աղբյուրի կանոն, որը բավական նեղ է վստահելու համար

Երթուղիչը դարձրեք այն աղբյուրը, որին պատասխանում է հեռավոր հոսթը։ Այս դասավորության մեջ WAN հասցեն 203.0.113.24 է, LAN-ը՝ 192.168.88.0/24, երթուղիչի թունելի հասցեն՝ 172.20.5.1, և ծառայությունը պատասխանում է 172.20.5.40:8443 հասցեով։ Ներքևի կանոնը համընկնում է նպատակակետի թարգմանությունից հետո փաթեթի հետ, դրա համար էլ նշում է թարգմանված հասցեն, ոչ թե հանրայինը։ Դրանում ոչինչ կախված չէ հաճախորդի հասցեից, և հենց դա է իմաստը։

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

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

Երբ համատարած քողարկումը ազնիվ ընտրություն է

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

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

Ստուգեք հաշվիչները հրապարակելուց առաջ

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

iptables -t nat -L POSTROUTING -v -n --line-numbers

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