Տնային լաբորատորիայի հիպերվիզորը հասանելի չէ VPN-ով. որտեղ նայել
Թունելը բարձրացած է, բայց հիպերվիզորի էջը չի բեռնվում։ Ստուգեք կառավարման սեգմենտը, վերադարձի ուղին դեպի հաճախորդների լողավազանը, ապա հոսթի քաղաքականությունը։
Թունելը բարձրանում է, հիպերվիզորի վեբ էջը ժամանակը սպառում է, և հաճախորդն ասում է, որ միացած է։ Այդ համակցությունը զարմանալիորեն շատ բան բացառում է: VPN ձեռքսեղմումը աշխատում է, հաճախորդն ունի հասցե, և վերջնակետը հասանելի է։ Մնում է երթուղման և քաղաքականության հարցերի կարճ ցանկ, և դրանք բնական հերթականություն ունեն։ Աշխատեք դրանց վրա հիպերվիզորից դեպի դուրս, ոչ թե հաճախորդից դեպի ներս, որովհետև հիպերվիզորի սեփական վիճակը հաստատելու ամենաէժան բանն է։
Սկսեք կառավարման սեգմենտից
Հաստատեք հիպերվիզորի կառավարման հասցեն և դրա վրա լսող ծառայությունը, և հաստատեք, որ էջը բեռնվում է այդ սեգմենտի մեկ այլ հոսթից, նախքան հեռավոր որևէ բան ախտորոշելը։ Տեղական թեստը, որը ձախողվում է, VPN խնդիր չէ, և դա հինգ րոպեանոց ստուգում է, որը խնայում է մեկ ժամ։
Ապա երկու ուղիները։ VPN հաճախորդին պետք է երթուղի դեպի կառավարման ցանց, ինչը սովորաբար նշանակում է, որ հաճախորդի AllowedIPs կամ հրող երթուղիները ներառում են այդ ենթացանցը։ Հիպերվիզորին կամ նրա լռելյայն դարպասին պետք է վերադարձի ուղի դեպի հաճախորդների հասցեների լողավազան, եթե նախագիծը մուտքի մոտ դիտմամբ չի թարգմանում աղբյուրը։ Դրանք երկու առանձին փաստ են, և դրանցից որևէ մեկի բացակայությունը տալիս է նույն ժամանակի սպառումը։ Ստուգեք դրանք առանձին: ip route get 192.168.10.20 հաճախորդի վրա, և գրավում հիպերվիզորի հոսթի վրա, որը ցույց կտա՝ փաթեթը հասել է ընդհանրապես, թե ոչ։
Թույլատրեք իրական հեռավոր ադմինիստրատորին
Լիազորումը հասանելիությունից առանձին հարց է։ Օգտագործեք դարպասի և հոսթի քաղաքականություն՝ սահմանափակված այն աղբյուրներով և ծառայություններով, որոնց պետք է կառավարման հասանելիություն։ Հյուր VPN հաշիվը, որին պետք է մեկ լաբորատոր հավելված, չպետք է դրանով հասնի կառավարման հարթությանը, և հարթ կանոնը, որը թույլ է տալիս ամբողջ թունելի ենթացանցը, հենց այդպես է դա տեղի ունենում։
Թողեք միացված հիպերվիզորի սեփական նույնականացումը և վկայագրի ստուգումները։ Մասնավոր երթուղին պատճառ չէ անցնելու անսպասելի ինքնության նախազգուշացման միջով։
Արժե նախազգուշացումը դիտել որպես հայտնաբերում, ոչ թե խոչընդոտ։ Եթե վկայագիրը չի համապատասխանում ձեր օգտագործած անվանը, ապա կամ անունը սխալ է, կամ ծառայությունը այն չէ, ինչ դուք կարծում եք, և երկու պատասխաններն էլ ավելի կարևոր են կառավարման ինտերֆեյսում, քան ցանկացած այլ տեղ։ Հասեք էջին այն անվանով, որի համար տրվել է վկայագիրը, և թողեք DNS-ը այդ անունը ուղղի թունելի հասցեին։ Մասնավոր անուն, որը LAN-ի և թունելի միջև անհետևողականորեն լուծվում է վկայագրի բողոքների սովորական պատճառ է, որոնք նման են VPN խափանումների։
Ստուգեք երկրորդական միացումները
Որոշ գործառույթներ օգտագործում են միացումներ, որոնք վեբ էջը չի օգտագործում։ Կոնսոլի սեսիան, ISO վերբեռնումը, VNC կամ SPICE վստահված սերվերը և միգրացիայի ալիքը կարող են յուրաքանչյուրն օգտագործել այլ պորտ կամ այլ հոսթի հասցե։ Երբ էջը բեռնվում է, և մեկ գործառույթ ձախողվում է, կարդացեք այդ արտադրանքի պահանջը՝ հոսթի վրա բոլոր պորտերը բացելու փոխարեն։
Ամեն ինչ բացելը հենց այն ճանապարհն է, որով կառավարման ինտերֆեյսը դառնում է չկառավարվող։ Յուրաքանչյուր լրացուցիչ պորտ ևս մեկ լսող է, որը պետք է թարմացված պահել, և հիպերվիզորն արդեն բավական բան է ցուցադրում։ Բացահայտեք այն կոնկրետ միացումը, որն անհրաժեշտ է գործառույթին, հաստատեք, որ այն հասանելի է թունելի միջով, և թողեք մնացածը փակ։ Եթե գործառույթը պնդում է ուղիղ միացում հոսթի հասցեին, որը հնարավոր չէ երթուղել ձեր թունելով, դա նախագծային սահմանափակում է, որը պետք է դիտմամբ շրջանցել, ոչ թե տիրույթ փոխանցելու պատճառ։
Պահեք վերադարձի ճանապարհը՝ նախքան ցանցին դիպչելը
Նախքան ձեր սեփական VPN-ը կրող վիրտուալ ցանցը փոխելը, հաստատեք, որ ունեք տեղական կամ անկախ վերադարձի ճանապարհ։
Սա ամենից շատ կարևոր է տնային լաբորատորիայում, որովհետև VPN վերջնակետը հաճախ վիրտուալ մեքենա է հենց այն հիպերվիզորի վրա, որին փորձում եք հասնել։ Վիրտուալ անջատիչը, կամուրջը կամ հրապատի կանոնը հեռավոր փոխելը կարող է հեռացնել այն ուղին, որն օգտագործում եք, և սեսիան կարող է բավական երկար ապրել, որպեսզի տեսնեք դա։
Փորձեք լաբորատորիայից դուրս, ոչ թե LAN-ից, և ստուգեք մերժումները այնպես, ինչպես թույլտվությունները։ Ցանցը, որը պետք է մնա անհասանելի թունելից, պետք է մնա այդպիսին նաև ձեր փոփոխությունից հետո, և դա առանձին պնդում է կառավարման էջի բեռնումից։ Գրեք երկու արդյունքները, որովհետև երկրորդն է, որ բաց է թողնվում, և հենց դա է կարևոր, երբ լաբորատորիան մեծանում է։
Պահպանվող գրառումը կարճ է: կառավարման հասցեն և ծառայությունը, յուրաքանչյուր կողմի պահանջած երթուղին, հասանելիության թույլտվություն ունեցող ինքնությունները և վերականգնման ուղին։ Դա բավական է, որպեսզի հաջորդ մարդը վերարտադրի աշխատող վիճակը՝ առանց այն նորից ածանցելու։
Եթե էջը այս ամենից հետո էլ ժամանակը սպառում է, գրավեք հիպերվիզորի վրա և փնտրեք փաթեթը՝ նախքան ևս մեկ կանոն փոխելը։ Փաթեթը, որը երբեք չի հասնում, երթուղման կամ հրապատի հարց է: փաթեթը, որը հասնում է և մերժվում, ծառայության կամ քաղաքականության հարց է: փաթեթը, որը հասնում է և պատասխան ստանում, մինչ հաճախորդը սպասում է, վերադարձի ուղու հարց է։ strongSwan-ի փոխանցման փաստաթղթերը բացատրում են, թե ինչպես Linux դարպասը թունելի տրաֆիկը փոխանցում է ներքին հոսթին։ Երեք գրավում ավելի լավ է, քան ևս մեկ ենթադրություն։