Ինչու լրիվ թունելով VPN-ը թաքցնում է ձեր երթուղավորված տեղական VLAN-ները
allow local network տարբերակը ոչինչ չգիտի ձեր երթուղիչի հետեւում գտնվող VLAN-ների մասին։ Տեղական դարպասով անցնող կոնկրետ երթուղին պահում է պահեստավորման եւ լաբորատորիայի ենթացանցերը հասանելի։
VPN-հաճախորդի «allow local network» անջատիչը հնչում է այնպես, կարծես ծածկում է շենքում ամեն ինչ։ Գործնականում այն սովորաբար ավելացնում է մի քանի մասնավոր հասցեների բացառություն թունելի լռելյայն երթուղուն եւ այնտեղ կանգ առնում։ Ձեր պահեստավորման VLAN-ը հասանելի է մնում միայն այն դեպքում, երբ այդ կոնկրետ նախածանցի երթուղին վերապրում է թունելի ժամանումը, եւ շատ հաճախորդների դեպքում դա տեղի չի ունենում։
Սա երթուղավորման, ոչ թե VPN-ի կարգավորման հարց է, ինչը լավ նորություն է՝ այն ունի կոնկրետ պատասխան։
Ինչ է իրականում ծածկում allow-local-network-ը
Հաճախորդները այդ տարբերակը տարբեր կերպ են իրականացնում։ Ոմանք երթուղիներ ավելացնում են այն ենթացանցի համար, որին միացված է մեքենան, ոմանք ավելացնում են RFC 1918 միջակայքերը, իսկ մի քանիսը բացառում են միայն լռելյայն դարպասը։ Նրանցից ոչ մեկը չգիտի, որ ձեր գրասենյակի երթուղիչը սպասարկում է նաեւ պահեստավորման VLAN, լաբորատոր հատված կամ տպիչի ենթացանց, որովհետեւ այդ նախածանցերը այն լարի վրա չեն, որը տեսնում է հաճախորդը։ Կարդացեք հաճախորդի սեփական փաստաթղթերը ճշգրիտ վարքագծի մասին՝ փոխարենը ենթադրելու, որ պիտակը նկարագրում է ձեր տոպոլոգիան։
Տարբերությունը ամենակարեւորն է լրիվ թունելի ձեւավորման մեջ, որտեղ հաճախորդը դիտավորյալ փոխարինում է լռելյայն երթուղին, որպեսզի ամբողջ երթեւեկությունը գնա VPN-ով։ Դա է ձեւավորման ամբողջ իմաստը, եւ դա է, որ ստիպում է տեղական երթուղավորված ցանցերին անհետանալ։ Դրանք երբեք չեն ծածկվել սեփական երթուղով; դրանք ընթանում էին հենց նոր փոխարինված լռելյայն երթուղով։ Հաճախորդը չի կարող երթուղավորել այն, ինչի գոյության մասին չգիտի, եւ նա սովորում է միայն իր սեփական ինտերֆեյսին կցված նախածանցերի մասին։ Մնացած ամեն ինչ պետք է նկարագրի մեկը, ով գիտի տոպոլոգիան։
Միացված երթուղիները կանգ են առնում առաջին երթուղիչի մոտ
192.168.10.20/24 հասցեով աշխատանքային կայանը 192.168.10.1 դարպասով ինքնաբերաբար ստանում է միացված երթուղի 192.168.10.0/24-ի համար։ 192.168.20.0/24 հասցեով պահեստավորման VLAN-ը այլ նախածանց է, հասանելի միայն այդ դարպասով, եւ աշխատանքային կայանը դրա համար երթուղի չունի լռելյայնից բացի։ Մինչ թունելը վեր կկենա, սովորական լռելյայն երթուղին պատահաբար պահեստավորման երթեւեկությունը ուղարկում է 192.168.10.1-ին, եւ ամեն ինչ աշխատում է։
Երբ VPN-ը տեղադրում է լրիվ թունելի լռելյայն երթուղին, 192.168.20.1-ի փաթեթները հետեւում են նոր լռելյայնին դեպի թունել։ Հեռավոր դարպասը պատկերացում չունի, թե որտեղ է ապրում այդ նախածանցը, ուստի այն դեն է նետում դրանք կամ փոխանցում անօգուտ տեղ։ Պահեստավորման VLAN-ում ոչինչ սխալ կարգավորված չէր; նրա ուղին փոխառված էր, եւ փոխառությունը հետ կանչվեց։
Գայթակղությունը լայն բացառության ձգտելն է, օրինակ /1 երթուղիների զույգ կամ երկրորդ լռելյայն։ Դիմացեք դրան։ Որքան նեղ է բացառությունը, այնքան ավելի հեշտ է այն բացատրել, ստուգել եւ հեռացնել, երբ ցանցը փոխվի։
Դրեք բացառությունը այն աղյուսակում, որը հաղթում է
Մեկ երթուղավորման աղյուսակում /24-ը հաղթում է /0-ին կամ /1-ին ամենաերկար նախածանցի համընկնմամբ, ուստի տեղական դարպասով դեպի պահեստավորման VLAN կոնկրետ երթուղին բավարար է, պայմանով, որ աղյուսակը ընդհանրապես դիտարկվի։ Linux-ում սովորական ձեւը կարճ է.
ip route add 192.168.20.0/24 via 192.168.10.1 dev eth0Քաղաքականությամբ երթուղավորումը բարդացնում է այդ երաշխիքը։ Ավելի վաղ կանոնը կարող է երթեւեկությունն ուղարկել այնպիսի աղյուսակ, որի սեփական լռելյայն երթուղին ուղղված է թունելի մեջ, եւ այդ դեպքում ձեր /24-ը պարունակող հիմնական աղյուսակը երբեք չի հասնվում։ Ստուգեք կանոնները նախքան երթուղին հեղինակավոր համարելը, որովհետեւ սխալ աղյուսակում ճիշտ թվացող գրառումը բացատրում է կոտրված երթուղու նման ձախողում։
Ապա գրառումը դարձրեք մշտական հաճախորդի աջակցած մեխանիզմով կամ ինտերֆեյսին տիրող ցանցի կառավարիչով։ Հուշման մեջ մուտքագրված երթուղին անհետանում է հաջորդ վերամիացման ժամանակ, եւ մեկ Wi-Fi դարպասին կապված երթուղին տեղափոխելի չէ դյուրակիր համակարգչի այցելած հաջորդ ցանց։
Անունները եւ քաղաքականությունը չեն հետեւում երթուղիներին
Երթուղին ուղղելը վերականգնում է փաթեթները, ոչ անունները։ Եթե տեղական սարքերը լուծվում են պարտադրված լուծիչի միջոցով, որը նրանց մասին ոչինչ չգիտի, ամրացումը դեռ ձախողվում է, թեեւ հասցեն հասանելի է։ Տեղական անունները պահանջում են տեղական կամ բաժանված DNS կարգավորում, եւ դա առանձին որոշում է երթուղու բացառությունից։
Քաղաքականությունը կրկին առանձին է։ VPN-հաճախորդի տեղական հասանելիության զտիչը կարող է դիտավորյալ արգելել երթեւեկությունը դեպի մասնավոր միջակայքեր, եւ երթուղին չի վերացնում այդ կանոնը։ Ոչ վստահելի ցանցում մասնավոր հասցեն նույնպես ապացույց չէ, որ նպատակակետը ձեր պահեստավորման սերվերն է, ուստի բացառությունը պետք է լինի նույնքան կոնկրետ, որքան ինքը երթուղին։
Պայմանագիր, որը կարող եք հանձնել
Ավարտված ձեւավորումը պետք է կարդացվի որպես կարճ ցուցակ: ընդհանուր ինտերնետ երթեւեկությունը հետեւում է թունելին, եւ այս անվանված տեղական նախածանցերը պահպանում են իրենց ուղին տեղական երթուղիչով։ Գրեք նախածանցերը, հաջորդ ցատկը եւ նրանց հետ գնացող DNS վերջածանցը, եւ ցուցակը պահեք այնքան կարճ, որ ինչ-որ մեկը կարողանա ստուգել այն առանց երթուղավորման աղյուսակ կարդալու։
Ուշադիր եղեք տեղական եւ հեռավոր միջակայքերի համընկնմանը։ Պահեստավորման VLAN-ը, որը նախածանցը կիսում է VPN-ի հետեւում գտնվող ինչ-որ բանի հետ, կլուծվի այն երթուղու, որը ավելի կոնկրետ է, եւ արդյունքում վարքագիծը շփոթեցնող է այնպես, որ ընդհատվող է թվում։ Մի կողմի վերահամարակալումը սովորաբար ավելի էժան է, քան անորոշությունը հավերժ վրիպազերծելը։
Փորձարկեք պայմանագիրը երկու անգամ՝ մեկ անգամ թունելը վեր, մեկ անգամ այն վար։ Եթե տեղական ուղին աշխատում է միայն այդ վիճակներից մեկում, բացառությունը դեռ պայմանագիր չէ։