Դատարկ LAN խաղերի ցանկ OpenVPN-ով? Ստուգեք հայտնաբերման ուղին

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

Առանձնացրեք սեսիային միանալը դրա գտնելուց

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

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

Փորձեք ուղիղ միացում նախքան թունելին դիպչելը

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

Չենթադրեք, որ հայտնաբերման պորտը և սեսիայի պորտը նույն թիվն են։ Խաղերը սովորաբար հայտարարում են մեկ UDP պորտով և խաղացողներ ընդունում մյուսով, իսկ սխալ պորտի համար կառուցված ռելեյը տալիս է ցանկ, որը մնում է դատարկ։

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

Հասկացեք, թե որտեղ է կանգ առնում broadcast-ը

Երթուղավորված TUN թունելը IP փաթեթներ է տեղափոխում հավասարների միջև և չի վերարտադրում տեղական broadcast-ը յուրաքանչյուր հավասարի ցանցում։ Սահմանափակ broadcast հասցեն 255.255.255.255 մնում է այն թողարկող ինտերֆեյսի ներսում, իսկ ենթացանցին ուղղված broadcast-ը առանձին դեպք է, ոչ թե ընդհանուր լիցենզիա երթուղիչներին հայտարարություններով ողողելու համար։

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

Multicast հայտնաբերումն ունի նույն խնդիրը մեկ այլ հասցեների դասի հետ, և այն պահանջում է multicast երթուղավորում կամ ռելեյ, այլ ոչ թե broadcast-ի բացառություն։

Երբ ռելեյը հիմնավորված է, պահեք այն նեղ

Եթե ավտոմատ հայտնաբերումը պահանջ է, նախ բացահայտեք փաստացի փոխանակումը՝ broadcast կամ multicast, նպատակակետի հասցե, UDP պորտ, այն ուղարկող ինտերֆեյսը և պատասխանի ներսում եղած հասցեն։ Այդ հինգ փաստերով սահմանափակված և արձանագրությանը համապատասխան ռելեյը շատ ավելի նեղ է, քան ամբողջ Ethernet հատվածը երկարացնելը։

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

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

Կամուրջ միայն այն ժամանակ, երբ նախագիծը պահանջում է Ethernet

Ethernet շրջանակները շարժվում են TAP-ի ներսում, ուստի TAP թունելը կարող է պատկանել դիտավորյալ կամրջված broadcast տիրույթի։ Պարզապես dev tun-ից dev tap-ի անցումը չի կառուցում այդ կամուրջը, չի դարձնում սերվերի կարգավորումը համատեղելի և չի ստիպում հավելվածին ընտրել նոր ինտերֆեյսը։ OpenVPN-ի կամրջման ուղեցույցը նկարագրում է ավելի լայն դասավորությունը, այլ ոչ թե մեկ դատարկ լոբբիի բուժում։

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

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