Ամբողջական թունել, թե վերջնակետի երթուղի. VPN սերվերը հասանելի պահելը

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

Երկու մեխանիզմ կանխում են այդ օղակը։ Մեկը տեսանելի է երթուղային աղյուսակում, մյուսն ապրում է հավելվածի ներսում։

Ներքին և արտաքին երթևեկությունը տարբեր որոշումներ են

Հավելվածի փաթեթը մտնում է վիրտուալ ինտերֆեյս և ինկապսուլացվում է։ Արդյունքը նոր փաթեթ է՝ հասցեագրված սերվերի հանրային հասցեին։ Այդ փաթեթին երթուղի է պետք ֆիզիկական ցանցում, քանի որ դրա ոչ մի մաս չի կարող մտնել թունել։

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

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

Առաջին տարբերակ: հոսթի երթուղի վերջնակետի համար

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

Նրա թուլությունը ի հայտ է գալիս, երբ փոխվում է հիմքում ընկած ուղին. Պահված երթուղին նշում է դարպաս և ինտերֆեյս հին ցանցից։ Wi-Fi-ի փոփոխությունից հետո այդ դարպասը կարող է չլինել, և երթուղին մնում է հետևում՝ ճիշտ տեսք ունենալով և ոչինչ չանելով։

# before the tunnel: which path reaches the endpoint?
ip route get 198.51.100.7

# pin it through the current gateway
ip route add 198.51.100.7/32 via 192.168.1.1 dev wlan0

# after the tunnel is up, confirm the pin survived
ip route get 198.51.100.7

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

Երկրորդ տարբերակ: պաշտպանել սոքեթը

Մյուս մոտեցությունը երբեք չի դիպչում երթուղային աղյուսակին։ Հաճախորդը նշում կամ պաշտպանում է թունելը կրող սոքեթը, ուստի օպերացիոն համակարգը քաղաքականությամբ ուղարկում է այդ սոքեթի երթևեկությունը թունելից դուրս։ Android-ը մեխանիզմն ուղղակիորեն տրամադրում է VPN հավելվածներին։ Սեղանադիր հաճախորդները համարժեքներն իրականացնում են ֆայրվոլի նշաններով կամ սարքին կապելու կանչերով։

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

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

Ընտրություն նրանց միջև

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

Մեխանիզմներից ոչ մեկը չի վերացնում սերվերի հասցեի ընդհանրապես հասանելի լինելու անհրաժեշտությունը։ Մասնավոր դարպասն ունի հանրային լսող հասցե, և հենց այդ հասցեն պետք է մնա թունելից դուրս։ Դրա հետևում գտնվող ներքին ցանցերը հասանելի են դառնում միայն թունելի գոյությունից հետո։

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