Հրապարակել LAN ծառայություն VPN դարպասի սեփական հասցեում

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

Սկսեք հաճախորդի տեսանկյունից

Այս օրինակի հաճախորդը գտնվում է VPN լողավազանում՝ 10.62.0.0/24-ում, և միանում է 10.62.0.1-ին 8080 պորտով։ Այդ հասցեն պատկանում է հենց դարպասին, ուստի փաթեթը հասնում է դարպասի միջուկին, ոչ թե մեկ այլ գործընկերոջ։ Դարպասի հետևում LAN-ը 172.21.4.0/24 է։ Դարպասին պատկանում է 172.21.4.10-ը, իսկ HTTP-ն իրականում սպասարկող սարքը 172.21.4.40-ն է։

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

Սահմանափակեք նպատակակետի թարգմանությունը դիտավորյալ

Նեղ տարբերակը ներկայացնում է մեկ պորտ և վերագրում է միայն նպատակակետը։ Փաթեթը պահպանում է իր արձանագրությունն ու աղբյուրը, և հենց դա է շրջագայության մնացած մասը հետաքրքիր դարձնում։

iptables -t nat -A PREROUTING -i tun0 -s 10.62.0.0/24 -d 10.62.0.1 -p tcp --dport 8080 -j DNAT --to-destination 172.21.4.40:80

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

Թույլ տվեք, որ փոխանցման սահմանը համաձայնի

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

iptables -A FORWARD -i tun0 -o lan0 -d 172.21.4.40 -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

Սարքը պետք է ինչ-որ կերպ պատասխանի

Թարգմանությունից հետո սարքը տեսնում է աղբյուր 10.62.0.0/24-ում։ Նրա պատասխանը գնում է իր լռելյայն դարպասին, որը LAN երթուղիչն է, ոչ թե VPN դարպասը, եթե ինչ-որ բան այլ բան չասի։ Երկու դասավորություն շտկում է դա, և դրանք համարժեք չեն։ Երթուղին սարքում կամ LAN երթուղիչում ուղարկում է 10.62.0.0/24-ը 172.21.4.10-ին՝ պահպանելով հաճախորդի աղբյուրը։ Սահմանափակ աղբյուրի թարգմանությունը փոխարենը թաքցնում է հաճախորդին դարպասի LAN հասցեի հետևում։

ip route add 10.62.0.0/24 via 172.21.4.10 dev eth1
iptables -t nat -A POSTROUTING -s 10.62.0.0/24 -d 172.21.4.40 -o lan0 -p tcp --dport 80 -j SNAT --to-source 172.21.4.10

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

Մի՛ փորձարկեք հենց դարպասից

Դարպասի վրա 10.62.0.1-ին ստեղծված հարցումը դուրս է գալիս OUTPUT շղթայով, ոչ թե մուտքային PREROUTING-ով։ Դրա ձախողումը կամ հաջողությունը ոչինչ չի ասում հաճախորդին ուղղված կանոնի մասին, և այդպես են մարդիկ եզրակացնում, որ աշխատող կանոնը կոտրված է։

conntrack -L | grep 172.21.4.40
tcpdump -ni any 'port 8080 or port 80'

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