Wi-Fi հաճախորդների մեկուսացումն ընդդեմ VPN տեղական մուտքի. ինչն է ձեզ արգելափակում
Նույն SSID-ում երկու սարք կարող են չհասնել միմյանց։ Համեմատեք, թե ինչ է արգելափակում Wi-Fi հաճախորդների մեկուսացումը և ինչ է երթուղավորում VPN թունելը։
Դրեք երկու հեռախոս նույն հյուրային SSID-ում, և ոչ մեկը չի տեսնում մյուսին, բայց երկուսն էլ հասնում են ինտերնետ։ Ավելացրեք VPN հաճախորդ դրանցից մեկին, և երեք մետր հեռավորության վրա գտնվող տպիչը մնում է անտեսանելի, մինչդեռ մեկ այլ մայրցամաքում գտնվող սերվերը պատասխանում է ping-երին։ Թունելում ոչինչ կոտրված չէ. գործում են երկու առանձին մուտքի որոշումներ, և դրանցից միայն մեկն է երթուղավորման մասին։ Մուտքի կետը որոշում է՝ անլար հաճախորդները կարող են խոսել միմյանց հետ, թե ոչ, իսկ VPN հաճախորդը որոշում է, թե որ նպատակակետերն են դուրս գալիս թունելով։ Այս երկուսը շփոթելը տալիս է ժամերով անիմաստ կարգավորումների փոփոխություններ։
Երկու դարպասները անկախ են
Հաճախորդների մեկուսացումը կոմուտացիայի որոշում է։ Մուտքի կետը ընդունում է կադր մեկ միացված կայանից, նայում է նպատակակետին, նկատում, որ նպատակակետը նույն կամրջի վրա գտնվող մեկ այլ կայան է, և գցում է այն։ Կայանի IP հասցեն այդ որոշման համար էական չէ, և VPN-ը նույնպես։
Երթուղավորումը մեկ այլ որոշում է, որը կայացվում է հաճախորդում։ VPN-ի երթուղիների աղյուսակը որոշում է՝ 192.168.1.50-ի համար նախատեսված փաթեթը մտնում է թունել, թե դուրս է գալիս Wi-Fi միջերեսով։ Եթե փաթեթը դուրս է գալիս Wi-Fi-ով, և մուտքի կետը մեկուսացնում է հաճախորդներին, այն մահանում է մուտքի կետում։ Եթե փաթեթը մտնում է թունել, մուտքի կետը երբեք չի տեսնում սկզբնական նպատակակետը և չի կարող որևէ բան մեկուսացնել։
Ինչ է արգելափակում մեկուսացումը տիպիկ մուտքի կետում
Արտադրողները սա մատակարարում են մի քանի անուններով՝ հաճախորդների մեկուսացում, AP մեկուսացում, կայանների մեկուսացում կամ հյուրային ցանց, որը ենթադրում է այն։ OpenWrt-ում յուրաքանչյուր միջերեսի ընտրանքը անլար կազմաձևման ներսում isolate-ն է, ինչպես նկարագրված է անլար ցանցի փաստաթղթերում, և հյուրային SSID-ը սովորաբար ստանում է իր կամուրջը և firewall-ի գոտին։ Արդյունքն այն է, որ հաճախորդների միջև unicast կադրերը չեն կամրջվում, ուստի հարևանին ուղղված ping-ը, SMB միացումը կամ տպագրության աշխատանքը ձախողվում է, թեև երկու սարքերն էլ ցույց են տալիս լրիվ ազդանշան։
Հայտնաբերման արձանագրություններն առաջինն ու ամենատեսանելիորեն են տուժում։ Տպիչների և մեդիա սարքերի mDNS-ը multicast-ով գնում է 224.0.0.251, SSDP-ն օգտագործում է 239.255.255.250, և թե արդյոք այդ կադրերը հատում են կամուրջը, կախված է արտադրողից և նրանից, թե արդյոք միացված է multicast-ից unicast փոխարկումը։ Ցանկից բացակայող սարքն ավելի թույլ ապացույց է, քան հայտնի հասցեին ուղղված ձախողված ուղիղ միացումը։
Ինչ է փոխում VPN-ը, և ինչ չի կարող փոխել
Լրիվ թունելը վերցնում է լռելյայն երթուղին, ուստի տեղական ենթացանցերին հասնում են միայն այն դեպքում, երբ հաճախորդը նրանց համար պահում է ավելի կոնկրետ երթուղի։ Բաժանված թունելները հակառակն են անում և նախագծմամբ պահպանում են տեղական մուտքը։ Կարգավորումներից ոչ մեկը չի կարող ստիպել մեկուսացնող մուտքի կետին կադր փոխանցել իր երկու հաճախորդների միջև, դրա համար էլ VPN հաճախորդում տեղական երթևեկությունը թույլատրելը անհրաժեշտ է, բայց ոչ բավարար։
Հակառակ դեպքը նույնքան տարածված է։ Մուտքի կետը թույլատրում է հավասարակից երթևեկությունը, VPN հաճախորդը բացառում է տեղական ենթացանցը թունելից, և տպիչը դեռ չի պատասխանում, որովհետև հոսթի firewall-ը Wi-Fi ցանցը համարում է հանրային։ Երեք շերտ, երեք տարբեր լռելյայն արժեքներ, և VPN-ի մատյանների մեծ մասում տեսանելի է միայն երթուղին։
Պարզեք, թե որ դարպասն է փակ
Սկսեք փորձարկումով, որը VPN-ը հանում է պատկերից. միացրեք երկու սովորական սարք նույն SSID-ին և փորձեք մեկից հասնել մյուսին ըստ հասցեի։ Եթե դա ձախողվի, մուտքի կետը մեկուսացնում է, և ոչ մի VPN կարգավորում չի ուղղի այն։ Եթե հաջողվի, անցեք հաճախորդին և Linux-ում գործարկեք ip route get 192.168.1.50 կամ Windows-ում՝ Find-NetRoute -RemoteIPAddress 192.168.1.50; ելքը նշում է այն միջերեսը, որը կօգտագործի փաթեթը։
Երբ երթուղին մատնանշում է Wi-Fi միջերեսին, փաթեթը դուրս է գալիս առանց գաղտնագրման, և հարցը դառնում է, թե արդյոք մուտքի կետը և հոսթի firewall-ը թույլատրում են դա։ Երբ երթուղին մատնանշում է թունելին, նպատակակետն ուղարկվում է VPN սերվերին, ինչը սխալ է նույն LAN-ի սարքի համար և սովորաբար նշանակում է, որ թունելի թույլատրվածների ցանկը չափազանց լայն է։
Տպիչի պորտին ուղիղ միացումը ավելի լավ փորձարկում է, քան հայտնաբերման ցանկը։ Linux-ում nc -vz 192.168.1.50 9100 կամ PowerShell-ում Test-NetConnection 192.168.1.50 -Port 9100 ասում է ձեզ, թե արդյոք հասցեն ընդհանրապես հասանելի է, նախքան որևէ ծրագրային մակարդակի զուգավորում քննարկման մեջ կմտնի։
Ընտրեք ուղղումը ձեր գտնվող ցանցի համար
Հյուրանոցային կամ հյուրային ցանցում մեկուսացումը դիտավորյալ է, և չպետք է փորձեք հաղթահարել այն։ Վերաբերվեք տեղական սարքին որպես անհասանելիի, օգտագործեք VPN-ը՝ հասնելու հոսթի, որը կարող է տպել կամ կիսվել, և դադարեք SSID-ին վերաբերվել որպես LAN։
Տանը հիմնական SSID-ում մեկուսացումն անջատելը խելամիտ է, երբ սարքերը ձերն են, մինչդեռ հյուրային SSID-ը մնում է մեկուսացված։ Կարգավորումը ապրում է մուտքի կետի անլար կազմաձևման մեջ, և դրա տեղը հենց այնտեղ է, ոչ թե յուրաքանչյուր հաճախորդի firewall բացառություններում։
Գրասենյակում ենթադրեք, որ մուտքի կետը, VLAN-ը և հոսթի firewall-ը բոլորը դիտավորյալ են։ Սրեք հարցը փորձարկումների արդյունքներով՝ փոխարենը խնդրելու անջատել մեկուսացումը, որովհետև հաճախորդներին առանձնացնող ցանցը սովորաբար ինչ-որ բան է պաշտպանում։
Ստուգեք հավելվածը, ոչ միայն ping-ը
Հաջող ping-ը ապացուցում է ուղին, ոչ թե ծառայությունը։ Տպիչները հաճախ ընդունում են հում 9100 կամ IPP 631-ի վրա, բայց մերժում են հայտնաբերումը, իսկ ֆայլերի համօգտագործումը պահանջում է 445 և աշխատող անվանական լուծում։ Հաստատեք այն պորտը, որն օգտագործում է հավելվածը, ապա նորից փորձեք իրական առաջադրանքը սարքում։
Ձեր գրառումներում երկու շերտերն առանձին պահեք՝ ինչ է թույլատրում Wi-Fi ցանցը, և ինչ է երթուղավորում VPN-ը։ Հաջորդ անգամ, երբ սարքն անհետանա ցանկից, այդ բաժանումը ձեզ կասի՝ որտեղ նայել առաջինը։