Ինչ պետք է թույլատրի VPS-ը նախքան ձեր VPN-ը հյուրընկալելը

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

Հաստատեք արձանագրությանը անհրաժեշտ ինտերֆեյսը

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

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

sudo ip tuntap add dev tun9 mode tun
sudo ip tuntap del dev tun9 mode tun
sudo ip link add wgtest type wireguard && sudo ip link del wgtest

Առաջին զույգի մերժումը նշանակում է, որ TUN-ը հասանելի չէ, և OpenVPN-ի լռելյայն ռեժիմը չի կարող սկսվել; վերջին տողի մերժումը նշանակում է, որ WireGuard-ի միջուկային ինտերֆեյսը բացակայում է։ Միջուկի TUN/TAP փաստաթղթերը նկարագրում են այն սարքը, որը փորձարկում է առաջին ստուգումը։ Երկու ձախողումներից ոչ մեկը չի շտկվում VPN փաթեթի վերընտեղադրմամբ։

Հիշեք, որ մուտքային ուղին երկու սեփականատեր ունի

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

UDP-ն սովորական զոհն է. շատ հարթակներ լռելյայն թույլատրում են TCP և UDP կանոնները դիտարկում որպես առանձին գրառում։ Եթե օրինակը գտնվում է մատակարարի NAT-ի հետևում՝ հանրային հասցե ունենալու փոխարեն, մատակարարի կողմում պորտերի փոխանցումը դառնում է համաձայնեցնելու երրորդ կոնֆիգուրացիան։

Պլանավորեք վերադարձի ուղին, ոչ միայն ելքը

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

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

sysctl -n net.ipv4.ip_forward
sudo nft list ruleset | head -n 40
ip -4 route show default

Վճռեք IPv6-ի հարցը հստակորեն

IPv6-ը գալիս է մի քանի մեխանիզմներով, որոնք դարպասի համար տարբեր կերպ են վարվում՝ հասցե օրինակի վրա, երթուղված նախածանց կամ ընդհանրապես ոչինչ։ Միայն երթուղված նախածանցը թույլ է տալիս սերվերին սովորական ձևով հասցեներ տալ client-ներին։ Այն ենթադրությունը, որ հոսթի վրա աշխատող IPv6 հասցեն նշանակում է օգտագործելի client նախածանց, սխալ է, որը հետագայում ի հայտ է գալիս որպես կիսով չափ կոտրված կապ։ Սա այն խափանման տեսակն է, որը վերապրում է միայն IPv4-ով արված յուրաքանչյուր փորձարկում։

Եթե մատակարարը ոչ մի նախածանց չի երթուղում, վճռեք՝ թունելը միայն IPv4-ի՞ համար է, և արդյոք client-ներին պետք է ասել այդ մասին։ Փաստաթղթավորված բացակայությունն ավելի ապահով է, քան մասնակի կոնֆիգուրացիան, որը լուռ IPv6 նպատակակետերը սև խոռոչ է նետում միացած օգտատերերի համար։

Ապացուցեք արտաքին client-ից

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

sudo wg show wg0 latest-handshakes
ip -4 route get 203.0.113.44
sudo journalctl -u wg-quick@wg0 -n 15 --no-pager

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