Ինչու նույն երթուղիչի հետևում միանում է միայն մեկ VPN հաճախորդ

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

Կարդացեք դարպասի մատյանը, նախքան հաճախորդին դիպչելը

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

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

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

Ինչ է անում երթուղիչը GRE-ի և NAT-T-ի հետ

PPTP-ն դասական մեղավորն է. կառավարման ալիքը TCP 1723 է, մինչ տվյալների ուղին GRE-ն է՝ IP արձանագրություն 47։ Շատ սպառողական երթուղիչներ գալիս են PPTP օգնականով, որը հետևում է մեկ կառավարման միացման, այնպես որ նույն NAT-ի հետևում գտնվող երկրորդ հաճախորդը բացում է իր կառավարման ալիքը և հետո ընդհանրապես տվյալների ուղի չի ստանում։ 47 համարի TCP պորտի փոխանցումը ոչինչ չի անում GRE-ի համար, որովհետև GRE-ն արձանագրության համար է, ոչ թե պորտ։

L2TP IPsec-ի վրա այլ կերպ է վարվում ըստ նախագծման. IKE-ն օգտագործում է UDP 500, NAT անցումը պաշտպանված բեռը տեղափոխում է UDP 4500, և փաթաթումը հենց դրա համար է, որ մեկ հասցեի հետևում գտնվող մի քանի հաճախորդներ կարողանան հասնել նույն դարպասին։ Այդ նախագիծը չի խանգարում դարպասին կամ միջանկյալ տուփին սահմանել նստաշրջանների սահման յուրաքանչյուր հասցեի համար, և բազմոցից երկու խափանումները նույն տեսքն ունեն։ SoftEther-ի սեփական արձանագրությունն ունի նույն դասի խնդիր. աշխատող անցկացում չունեցող երթուղիչը ներս է թողնում տեղական ցանցից առաջին հաճախորդին և դուրս գցում երկրորդին։ Փորձեք երթուղիչի ALG կամ անցկացման անջատիչը երկու դիրքերում էլ, որովհետև ավելի հին հաճախորդի համար գրված օգնականը կարող է վնասել փաթեթները, որ ուղարկում է ներկայիսը։

nc -vz 203.0.113.5 1723
sudo tcpdump -ni any proto gre

Ինքնության սահմաններ, որոնք նման են տրանսպորտի սահմանների

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

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

sudo journalctl -u openvpn-server@server -n 60 --no-pager
cat /run/openvpn/server.status

Համապատասխանեցրեք վերանորոգումը մատյանի գրառմանը

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

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

Երկու կենդանի նստաշրջանների ստուգում

Միացրեք երկու սարքերը միաժամանակ, գործարկեք նախատեսված ծրագիրը յուրաքանչյուրի վրա, ապա նորից միացրեք դրանցից մեկը և կրկնեք։ Երկրորդ պատկերակը, որ մի պահ հայտնվում է, երթևեկության մասին ոչինչ չի ապացուցում, և տասը րոպե անց ընկնող նստաշրջանը այլ խափանում է՝ այլ պատասխանատուով։ Համեմատեք, թե սերվերը վերջում ինչ է հայտնում, նրա հետ, ինչ տեսել են օգտվողները, որովհետև այդ երկու պատմությունները հաճախ չեն համընկնում։

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