Պորտի փոխանցում NAT-ի հետևում գտնվող WireGuard peer-ին՝ DNAT և SNAT

Զննարկիչը հարցում է անում https://203.0.113.10:8443, փրոքսին ընդունում է կապը, իսկ WireGuard peer-ի ծառայությունը երբեք չի պատասխանում։ DNAT կանոնն անում է իր գործը, ձախողվում է պատասխանը։ Հետևեք փաթեթին երկու թարգմանություններով և բացակայող կանոնը դառնում է ակնհայտ։ Ուղղումը ճիշտ hook-ում ևս մեկ NAT հայտարարություն է, ոչ թե նոր թունել։

Հետևեք մեկ հարցման սկզբից մինչև վերջ

Հարցումը հասնում է փրոքսիի հանրային ինտերֆեյսին՝ որպես աղբյուր ունենալով հաճախորդի հանրային հասցեն, իսկ որպես նպատակակետ՝ փրոքսիի հասցեն։ nat PREROUTING-ում DNAT կանոնը վերագրում է նպատակակետը peer-ի թունելի հասցեին՝ 10.90.0.2։ Այնուհետև երթուղայնացման որոշումը փաթեթն ուղարկում է wg0-ով դուրս, և փոխանցման ուղին ավարտված է։

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

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

Ավելացրեք վերադարձի թարգմանությունը

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

iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

POSTROUTING կանոնը միտումնավոր նեղ է՝ այն համընկնում է թարգմանված նպատակակետի և թունելի ինտերֆեյսի հետ, ուստի չի վերագրում wg0-ով պատահաբար դուրս եկող անկապ երթևեկությունը։ Լայն masquerade կանոն նույնպես կթաքցներ հաճախորդի հասցեն, բայց դա կաներ յուրաքանչյուր հոսքի համար և կդժվարացներ NAT աղյուսակի աուդիտը։

Տեղադրեք կանոնները այնտեղ, որտեղ գոյություն ունի թունելը

Թունելի հասցեին կամ ինտերֆեյսին հղվող կանոնները պետք է աշխատեն այն բանից հետո, երբ wg-quick-ը կազմաձևի այն։ Ինտերֆեյսը ստեղծվում է PreUp-ից առաջ, բայց հասցեները, MTU-ն, DNS-ը և երթուղիները կիրառվում են դրանից հետո, իսկ PostUp-ը աշխատում է, երբ այդ ամենը տեղում է։ Ավելացումները դրեք PostUp-ում, իսկ ջնջումները՝ PreDown-ում։

PostUp = iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PostUp = iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1
PreDown = iptables -t nat -D PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PreDown = iptables -t nat -D POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

Ջնջումները պետք է համընկնեն ավելացումների հետ token առ token՝ ներառյալ multiport-ի և ինտերֆեյսի համընկնումները։ Մեկ համընկնումով տարբերվող ջնջումը ոչինչ չի հեռացնում, և հաջորդ վերամիացումը ավելացնում է կանոնի երկրորդ պատճենը։ Մի քանի վերամիացումից հետո աղյուսակը պարունակում է կրկնօրինակներ, որոնք դժվար է կապել կոնֆիգուրացիայի տողի հետ։

Ստուգեք արդյունքը iptables -t nat -S-ով վերամիացումից հետո։ Եթե նույն կանոնը հայտնվում է երկու անգամ, PreDown տողը չի համընկնում, և մաքրումը լուռ ձախողվում է։

Փոխանցում, զտում և մյուս NAT-ը

Մշտապես միացրեք IPv4 փոխանցումը, ապա թույլատրեք փոխանցվող հոսքը զտիչ աղյուսակում։ DNAT-ը տեղի է ունենում FORWARD շղթայից առաջ, ուստի զտիչ կանոնը համընկնում է թարգմանված նպատակակետի հետ, ոչ թե հանրային հասցեի։ Եթե UFW-ն է կառավարում firewall-ը, արտահայտեք թույլտվությունը որպես երթուղու կանոն՝ սովորական host կանոնը չի ծածկում փոխանցվող երթևեկությունը։

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

NAT VPS-ում մատակարարը հանրային պորտը քարտեզագրում է մասնավոր հասցեի։ Քարտեզագրումը պետք է համընկնի ձեր հայտարարած պորտի հետ, և անհամապատասխանությունը նույն տեսքն ունի, ինչ կոտրված թունելը։ Հաստատեք մատակարարի քարտեզագրումը նախքան WireGuard-ի կազմաձևումը փոխելը։

Ստուգեք վերադարձի ուղին և ընդունեք ծախսը

Միացեք ցանցից, որը փրոքսիի LAN-ը չէ, ապա ստուգեք թարգմանությունների զույգը, քանի դեռ կապը բաց է՝

conntrack -L -p tcp --dport 8080
tcpdump -ni any tcp port 8080

conntrack գրառումը պետք է ցույց տա սկզբնական tuple-ը, թարգմանված tuple-ը և պատասխանի ուղղությունը։ Եթե պատասխանը բացակայում է, peer-ը չի ուղարկում թունելով, ինչը սովորաբար նշանակում է, որ SNAT կանոնը չի կիրառվել, կամ peer-ի սեփական firewall-ը գցել է հոսքը։

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

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