Միացած եք OpenVPN-ին, բայց ping կամ SMB համօգտագործում չկա։ Ստուգեք երեք դարպաս

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

Յուրաքանչյուր դարպաս ձախողվում է տարբեր ախտանիշով, և միայն առաջինն է VPN սերվերի վրա։

Փոխանցումը FORWARD շղթայի քաղաքականություն է

OpenVPN-ի լսողի ընդունումը տեղի է ունենում INPUT-ում, դրա համար թունելը կարող է միանալ, մինչդեռ LAN-ի ուղղված յուրաքանչյուր փաթեթ դեն է նետվում։ Այն տրաֆիկը, որը գալիս է tun0 -ից և դուրս է գալիս LAN ինտերֆեյսով, անցնում է FORWARD-ով, և այնտեղ լռելյայն DROP քաղաքականությամբ հոսթը լուռ դեն է նետում այն։ Նախքան ուրիշ ինչ-որ բանի դիպչելը ստուգեք և՛ sysctl-ը, և՛ շղթան՝ sysctl net.ipv4.ip_forward և iptables -L FORWARD -v -n։

Թույլատրեք այն ուղղությունը, որը ցանկանում եք, և դրան պատկանող պատասխանները, օրինակ՝ accept կանոն թունելի ինտերֆեյսից դեպի LAN ինտերֆեյս, գումարած stateful կանոն established և related տրաֆիկի համար։ Եթե LAN-ը գտնվում է մեկ այլ երթուղիչի հետևում, այդ երթուղիչին պետք է վերադարձի երթուղի դեպի կլիենտների լողավազան կամ source NAT VPN սերվերի վրա։ Հաստատեք այդ ուղին մեկ ping-ով նախքան նոր կանոններ ավելացնելը, որովհետև այն կանոնը, որին հնարավոր չէ հասնել, երբեք չի հայտնվում հաշվիչում։

SMB-ին պետք է մեկից ավելի պորտ

Ֆայլերի համօգտագործումը մեկ TCP 445 զրույց չէ։ Հայտնաբերումը օգտագործում է UDP 137 և 138, հին NetBIOS սեսիաները՝ TCP 139, իսկ ժամանակակից SMB սեսիաները՝ TCP 445։ Կանոնը, որը բացում է միայն 445-ը, ստեղծում է նյարդայնացնող դեպք, երբ քարտեզագրված սկավառակը աշխատում է, իսկ ցանցի դիտարկումը՝ ոչ, կամ հակառակը։

Թունելով մեծ փոխանցումները նույնպես բախվում են MSS խնդիրների, որոնք նման են կոտրված համօգտագործման։ SYN-ը, որը հայտարարում է LAN-ի ամբողջ սեգմենտի չափը, դեն է նետվում թունելի ավելի փոքր MTU-ի պատճառով, և կապը կախվում է ձեռքսեղմումից հետո։ MSS-ի սեղմումը փոխանցման ուղու վրա, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, վերացնում է այդ տեսակի կանգը։ Ստուգեք մի քանի մեգաբայթի պատճենով, այլ ոչ թե թղթապանակի ցանկով, որովհետև փոքր պատասխանները անցնում են նույնիսկ այն դեպքում, երբ մեծ փոխանցումները չեն անցնում։

Թունելի ադապտերը գալիս է որպես նոր ցանցային պրոֆիլ

Windows-ը յուրաքանչյուր ադապտեր դասում է ցանցային պրոֆիլի, և նոր թունելի ադապտերը սովորաբար ընկնում է Public-ի մեջ, որտեղ ֆայլերի և տպիչների համօգտագործման կանոնները արգելափակված են։ Դա ֆայլային սերվերի հոսթի firewall-ի որոշումն է, ոչ թե VPN սերվերի երթուղավորման խնդիր։ Փոխեք կատեգորիան միտումնավոր Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private -ով՝ համոզվելուց հետո, որ քաղաքականությունը թույլ է տալիս, որովհետև կատեգորիան փոխում է նաև, թե որ մուտքային կանոններն են գործում։

Նույն պրոֆիլը բացատրում է ping-ը, որը ձախողվում է, մինչդեռ TCP 445-ը հաջողվում է, քանի որ echo հարցումները Public-ում լռելյայն դեն են նետվում։

Անուններն ինքնուրույն չեն անցնում երթուղավորված թունելով

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

Եթե տեղակայումը դեռ կախված է WINS-ից, կարգավորեք այն կլիենտում՝ հեռարձակման տրաֆիկի հայտնվելուն սպասելու փոխարեն։ Նախ ստուգեք հասցեով, որպեսզի անվան ձախողումը չշփոթվի firewall-ի ձախողման հետ։

Ստուգեք մեկ շերտ միաժամանակ և կարդացեք առաջին ձախողումը

Բարձրացեք վերև՝ ping արեք թունելի դարպասին, ping արեք LAN հոսթին հասցեով, ապա բացեք ծառայության պորտը Test-NetConnection -ComputerName 10.8.0.5 -Port 445 -ով, և միայն դրանից հետո նույնականացվեք համօգտագործման մեջ։ Առաջին ձախողվող քայլը այն շերտն է, որը պետք է ուղղել, և յուրաքանչյուր հաջորդ քայլ աղմուկ է, մինչև այն անցնի։ Այն ping-ը, որը պատասխանում է, մինչդեռ պորտը փակ է մնում, մատնանշում է ֆայլային սերվերի սեփական firewall-ը, մինչդեռ պորտը, որը բացվում է լուռ ping-երի չնայած, մատնանշում է ICMP զտում։ Գրեք առաջին ձախողվող քայլը նախքան որևէ բան փոխելը, որովհետև երկրորդ փոփոխությունը թաքցնում է առաջինի արդյունքը։

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

Ձեր գրառումներում համօգտագործման հաշիվը առանձին պահեք VPN մուտքից, որովհետև հաջող թունելը ոչինչ չի ասում ֆայլերի թույլտվությունների մասին։ SMB-ն ինտերնետին բացելը բացակայող կանոնը շրջանցելու համար լուծում չէ։