SNAT, DNAT և Masquerade. ինչ է անում յուրաքանչյուր VPN NAT կանոնը

Տեղադրեք գրավում VPN դարպասի երկու կողմերում, և մեկ հոսք կարող է ցույց տալ չորս տարբեր հասցեներ։ Աղբյուր NAT-ը վերագրում է, թե որտեղից է փաթեթը պնդում, որ գալիս է, նպատակակետ NAT-ը վերագրում է, թե ուր է այն գնում։ Masquerade-ը երրորդ ուղղություն չէ, այն աղբյուր NAT-ի կանոն է, որը հասցեն վերցնում է ելքային ինտերֆեյսից՝ ֆիքսված արժեքի փոխարեն։ Անվանեք, թե երեքից որն է ձեզ իսկապես պետք, և «VPN-ը կոտրված է» տոմսերի մեծ մասը կվերածվի վերադարձի ուղու մասին հարցի։

Ինչ է վերագրում յուրաքանչյուր կանոն

Աղբյուր NAT-ը, սովորաբար գրվում է SNAT, փոխում է հոսքի աղբյուրի հասցեն, երբ այն լքում է երթուղիչը կամ դարպասը։ Ընդունող ծառայությունը պատասխանում է թարգմանված հասցեին, և թարգմանող տուփը հակադարձում է փոփոխությունը՝ օգտագործելով այդ կապի համար պահված վիճակը։ Linux-ում այդ վիճակն ապրում է conntrack-ում, դրա համար էլ conntrack -L-ը տպում է սկզբնական և պատասխան զույգերը կողք կողքի։

Նպատակակետ NAT-ը, DNAT-ը, փոխարենը փոխում է նպատակակետը։ UDP 51820-ի վրա հանրային հասցեին ուղղված փաթեթը կարելի է վերագրել ներքին WireGuard սերվերի 10.8.0.2:51820 հասցեով։ Այսպես տնային երթուղիչը կամ ամպային բեռնվածքի հավասարակշռիչը հրապարակում է VPN լսող, և դա ոչինչ չի ասում այն մասին, թե ինչ կարող է թունելը կրել դրանից հետո։

Masquerade-ը պատկանում է SNAT ընտանիքին։ Կանոնը ոչ մի հասցե չի նշում, այն օգտագործում է այն հասցեն, որն ունի ելքային ինտերֆեյսը փաթեթի դուրս գալու պահին։ Linux-ը տալիս է նրան իր սեփական թիրախը, և սա սովորական ընտրություն է WAN ինտերֆեյսում, որը հասցեն ստանում է DHCP-ից կամ PPPoE-ից։

Քարտեզը որտեղ է ապրում, դա է որոշում խափանումը

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

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

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

Masquerade թե բացահայտ SNAT

Համեմատեք երկուսին՝ ըստ նրանց խոստումների։ Masquerade-ը ընտրում է ելքի հասցեն, բացահայտ SNAT-ը ամրացնում է այն։ Կայուն հանրային հասցեով դարպասի վրա ամրացումը մատյաններին և գործընկերների թույլատրելի ցանկերին տալիս է մեկ կանխատեսելի արժեք։ Դինամիկ WAN կապի վրա ամրացված SNAT հասցեն սխալ է դառնում վարձակալության փոփոխման պահին, և հենց այդ դեպքի համար է ստեղծվել Masquerade-ը։

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

Քաղաքականության վրա հիմնված IPsec-ում է, որ սա ամենաշատն է կծում։ strongSwan-ի փոխանցման ուղեցույցը անցնում է IP փոխանցման միացման և հաճախորդների համար աղբյուր NAT կանոնի ավելացման միջով, և նույն փաստաթղթերը ծածկում են այն երթևեկության բացառումը, որը պետք է պահպանի իր սկզբնական հասցեն։ Թարգմանեք աղբյուրը նախքան անվտանգության քաղաքականության համընկնելը, և թունելը կարող է բարձրանալ, մինչ երթևեկությունը դեռ ընկնում է, որովհետև փաթեթն այլևս նման չէ բանակցված ընտրիչին։

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

Կանոնները Linux դարպասի վրա կարդալը

Հեռավար մուտքի դարպասը, որի հաճախորդները 10.8.0.0/24-ում են և WAN ինտերֆեյսը կոչվում է eth0, պահանջում է միացված փոխանցում և զտիչ քաղաքականություն, որը թույլ է տալիս հոսքը, նախքան որևէ NAT կանոն կօգնի։ iptables տարբերակը երկու ուղղություններն էլ պահում է nat աղյուսակում:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 51820 \
  -j DNAT --to-destination 10.8.0.2:51820

nftables ձևը օգտագործում է նույն երկու կեռերը՝ անվանված ինտերֆեյսով և բացահայտ շղթայով:

nft add rule ip nat postrouting ip saddr 10.8.0.0/24 oifname "eth0" masquerade
nft add rule ip nat prerouting iifname "eth0" udp dport 51820 dnat to 10.8.0.2:51820

Երկու հատվածներն էլ ենթադրում են, որ զտիչ շղթան արդեն ընդունում է փոխանցված հոսքը։ NAT-ը թույլտվության կանոն չէ, և ճիշտ թարգմանված փաթեթը դեռ կարող է դեն նետվել մեկ աղյուսակ անց։ Հաստատեք կենդանի քարտեզը conntrack -L-ով, հաստատեք, թե ինչ է բեռնված nft list ruleset-ով կամ iptables-save -t nat-ով, ապա գրավում արեք երկու ինտերֆեյսներում՝ տեսնելու, որ հասցեն իսկապես փոխվում է։

Խափանման եղանակներ, որոնք նման են վատ կանոնի

Մազակալի երթևեկությունը դասականն է։ Ներքին հաճախորդը, որը ներքին սերվերին հասնում է սերվերի հանրային հասցեով, ներս գնալու ճանապարհին պետք է DNAT, իսկ հետ դուրս գալու ճանապարհին՝ աղբյուրի թարգմանություն, այլապես սերվերը պատասխանում է ուղիղ հաճախորդին, և պատասխանը մերժվում է։ Ուղղումը երկրորդ՝ ավելի նեղ կանոնն է այդ ներքինից հանրային դեպքի համար, ոչ թե ավելի լայն Masquerade կանոն ամեն ինչի համար։

Կրկնակի թարգմանությունը լուռն է։ Հաճախորդը, որն արդեն օպերատորի մակարդակի NAT-ի հետևում է, ձեր դարպասին հասնում է հասցեով, որը հնարավոր չէ հետ երթուղավորել, ուստի նորից թարգմանում եք։ Աշխատում է, բայց մատյաններն այժմ կրում են մասնավոր հասցեավորման երկու ցատկ, և ցանկացած հետաքննության պետք են երկու քարտեզները։ Քաղաքականության վրա հիմնված IPsec-ը ավելացնում է երրորդ ոլորանը՝ թարգմանեք նախքան քաղաքականության համընկնումը և կստանաք SA, որը բարձրացած է առանց երթևեկության, ինչը կարդացվում է որպես հրային պատի սխալ, ոչ NAT-ի։

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

Ստուգաթերթ կանոնը պահելուց առաջ

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

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