Ինչու ձեր LAN-ը չի հասնում VPN-ի հաճախորդի ծառայությանը

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

Կոտրվածը թունելը չէ

Երկու ծայրերը նստած են մասնավոր տիրույթներում, ինչը սովորական դեպք է, ոչ սխալ կարգավորում։ 10.8.0.6-ի նման հասցեն իրական է թունելի ներսում և գոյություն չունի ոչ մի այլ տեղ, ուստի LAN-ը պատճառ չունի այնտեղ ինչ-որ բան ուղարկելու։ Նախքան երթուղմանը դիպչելը, հաստատեք, որ ծառայությունը թունելի ներսում հասանելի է ընդհանրապես. հաճախորդի վրա ss -ltn ցույց է տալիս, թե արդյոք լսողը կապված է 127.0.0.1-ին, LAN-ի ինտերֆեյսին, թե թունելի հասցեին։ Միայն loopback-ին կապված դեմոնը ոչ ոքի չի պատասխանում, բացի իրենից, և դա ոչ մի երթուղի, DNAT կամ պորտի փոխանցում չի փոխում։

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

Երթուղու ձևը՝ ասացեք LAN-ին, թե որտեղ է լողավազանը

LAN-ի դարպասի վրա ստատիկ երթուղին ամենամաքուր պատասխանն է, երբ LAN-ը և թունելի լողավազանը չեն համընկնում։ Ուղղեք լողավազանը դեպի այն մեքենան, որը ավարտում է թունելը:

ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12   # Windows, persistent

Դա ուղղում է միայն մեկ ուղղություն, այդ պատճառով այս փոփոխության կիսատ տարբերակները առաջընթացի տեսք ունեն։ Թունելի կողմին պետք է համապատասխան կեսը, այլապես պատասխանը թողնում է հաճախորդին իր իսկ լռելյայն երթուղով և մահանում ճանապարհին:

push "route 192.168.1.0 255.255.255.0"

Մեկ հաճախորդի հետևում, ոչ սերվերի հետևում գտնվող ենթացանցի համար սերվերին պետք են և՛ համակարգային երթուղի, և՛ iroute գրառում այդ հաճախորդի ֆայլում client-config-dir-ի տակ։ Առանց iroute-ի OpenVPN-ը գիտի, որ նախածանցը գոյություն ունի, և պատկերացում չունի, թե որ հաճախորդն է այն տիրապետում. փաթեթները գալիս են, և դեմոնին ոչինչ չի մնում դրանք համապատասխանեցնելու։

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

NAT-ի ձևը՝ DNAT դեպի ներս, և այն SNAT տողը, որը բոլորը բաց թողնում են

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

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1

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

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

Ինչու ճիշտ թվացող կանոնը դեռ գցում է փաթեթը

Այս ձախողումների մեծ մասը չէ այն կանոնի մեջ, որին նայում եք։ Ստուգեք չորս բան այս հերթականությամբ և կանգ առեք առաջինի վրա, որը չի համապատասխանում:

• Շղթաների հերթականությունը։ iptables -I տեղադրում է վերևում, իսկ -A ավելացնում է վերջում, ուստի ավելի վաղ թույլատրող կամ արգելափակող կանոնն է առաջինը որոշում։
• Սխալ շղթա։ Հենց երթուղիչին հասցեագրված երթևեկությունն անցնում է INPUT-ով, իսկ փոխանցվող երթևեկությունը երբեք չի դիպչում դրան։ Մեկ ծառայություն հրապարակելը կարող է կանոններ պահանջել երկուսում էլ։
• Ուղղության դրոշակներ։ -i tun0 համապատասխանում է հաճախորդներից եկող երթևեկությանը, իսկ -o tun0՝ նրանց ուղղությամբ գնացողին։ Սխալ դրոշակով REJECT-ը արգելափակում է մի բան, ինչը չէիք նկատի ունեցել։
• Աղբյուրի սահմանափակում։ Փոխանցումը, որն ընդունում է մեկ հաճախորդի հասցե, աշխատում է այդ հաճախորդից և լուռ գցում է ցանկացած այլ աղբյուր։

Զրո փաթեթային հաշվիչով կանոնը բոլորովին ուղու վրա չէ, և հաշվիչները կարդալը սխալ շղթայի խնդիրը սխալ կանոնի խնդրից տարբերելու ամենաարագ ձևն է։

Տեղական փոխանցումը, երբ LAN-ում ոչինչ հնարավոր չէ փոխել

SSH-ի տեղական փոխանցումը շրջանցում է ամբողջ հարցը։ Դրան պետք չէ երթուղի LAN-ում, հաճախորդի ֆայրվոլի համագործակցություն, և ոչ մի տեղ հրապարակված պորտ:

ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host

Ծառայությունն այդ ժամանակ հայտնվում է թունելը պահող մեքենայի localhost:3000-ի վրա, և ոչ մի այլ տեղ։ Սա է սահմանը՝ մեկ աշխատանքային կայան, մեկ պորտ, և փոխանցումը մահանում է սեսիայի հետ, եթե ինչ-որ բան այն նորից չմեկնարկի։ Փորձնական տվյալների բազան ստուգող ադմինիստրատորի համար սա ճիշտ գործիքն է։ Բայց տեսախցիկի կամ սկաների համար, որին պետք է հասնեն այլ մարդիկ, սա այդպիսին չէ, քանի որ յուրաքանչյուր օգտատեր իր փոխանցումը կունենար։

Նոր կանոն ավելացնելուց առաջ ստուգեք երկու ուղղություններն էլ

Թարգմանությունը հետքեր է թողնում, և դրանք կարդալը լավ է, քան գուշակելը։ VPN-ի հոսթի վրա conntrack -L ցույց է տալիս, թե արդյոք թարգմանությունը տեղի ունեցավ ընդհանրապես, iptables -t nat -L -n -v ցույց է տալիս, թե արդյոք հաշվիչները շարժվեցին, և tcpdump -ni any port 3000 ցույց է տալիս, թե որ աղբյուր հասցեն իրականում հասավ։ Հաճախորդի վրա ss -ltn հաստատում է, որ լսողը գտնվում է այնպիսի հասցեի վրա, որին թունելը կարող է հասնել։

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