VPN-ը միացված է, VM-ն անհասանելի՞։ Երթուղին, հավանաբար, երբեք խնդիրը չի եղել

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

Host-only ցանցավորումը ծրագրային ցանց է, որը պատկանում է հոսթին և կիսվում նրա հյուրերի հետ՝ առանձին ցանկացած ֆիզիկական միացումից։ VPN հաճախորդի սեփական ինտերֆեյսում ոչինչ չի փոխում այդ ցանցը, ուստի նախքան այն դիպչելը պարզեք, թե չորս շերտերից որն է իրականում ձախողվել։

Երթուղին սովորաբար դեռ տեղական է

Հարցրեք միջուկին, ոչ թե երթուղային աղյուսակի առաջին էջին։ Linux-ում ip route get 192.168.56.10-ը հայտնում է ճշգրիտ երթուղին, ինտերֆեյսը և աղբյուրի հասցեն, որոնք կօգտագործվեին, ինչը տարբեր պատասխան է լռելյայն երթուղին կարդալուց և գուշակելուց։ Եթե ելքը նշում է host-only ինտերֆեյսը, թունելն այդ ուղու վրա բացարձակապես ներգրավված չէ։

Երկու բան կարող է իսկապես կոտրել այն, և երկուսն էլ հասցեների, ոչ թե VPN-ի խնդիրներ են։ Հեռավոր ենթացանցը, որը համընկնում է host-only նախածանցի հետ, թույլ է տալիս հաղթել ավելի կոնկրետ երթուղուն, իսկ ավելի ցածր մետրիկով լայն երթուղի տեղադրող VPN հաճախորդը կարող է քաշել նախածանցը։ Երկուսն էլ երևում են նույն հրամանում. ելքում նշված ինտերֆեյսը կլինի թունելը, և ուղղումը պատկանում է նրան, ով տիրապետում է այդ հասցեային պլանին։

Երթուղու ընտրությունը և փաթեթի ընդունումը տարբեր որոշումներ են

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

Այսպիսով, ձախողումը հավելվածի կողմից նույնական է թվում երթուղավորման խնդրին, իսկ հաճախորդի կողմից՝ բոլորովին այլ։ Եթե ip route get-ը նշում է ճիշտ ինտերֆեյսը, և կապը դեռ ժամկետանց է լինում, դադարեցրեք երթուղիների խմբագրումը և փոխարենը կարդացեք հաճախորդի փաստաթղթավորված տեղական մուտքի վարքը։ Որոշ հաճախորդներ տեղական ենթացանցերի համար թույլատրվածների ցանկ են տրամադրում, ոմանք արգելափակում են ամեն ինչ, ինչը թունելը չէ, իսկ ոմանք արգելափակում են միայն այն դեպքում, երբ միացված է kill switch-ը։

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

Հյուրն ունի «ոչ» ասելու երեք եղանակ

Հյուրը, որը կարող է զննել ինտերնետը, ոչինչ չի ապացուցել ձեր ուզած ծառայության մասին։ Լսողը կարող է հյուրի ներսում կապված լինել 127.0.0.1-ին, և այդ դեպքում ոչ մի հարցում հոսթից չի կարող հասնել, որքան էլ լավը լինի ուղին։ Ստուգեք հյուրում ss -ltn-ով և նայեք տեղական հասցեի սյունակին, ոչ միայն պորտին։

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

Անցեք այդ երեքի միջով նախքան VM-ի ցանցային ռեժիմը փոխելը դիտարկելը։ Յուրաքանչյուրը ավելի փոքր փոփոխություն է, քան հյուրի միացման վերակառուցումը, և յուրաքանչյուրն ունի հստակ թեստ։

Ինչ է իրականում կամուրջը, և ինչ արժե այն

Ադապտերը կամրջի ռեժիմի անցկացնելը host-only ուղու վերանորոգում չէ։ Դա որոշում է հյուրին այլ ցանցում՝ սովորաբար ֆիզիկական LAN-ում, տեղադրելու մասին, որտեղ նա տեսանելի է դառնում այնտեղ ապրող մնացած ամեն ինչի համար։ Դա կարող է լինել հենց այն, ինչ ուզում եք։ Բայց դա այն չէ, ինչ անում էր սկզբնական կոնֆիգուրացիան։

Օգտագործեք այն, երբ հյուրն իսկապես պետք է լինի այդ LAN-ի հավասարը, և ազդեցությունը հաստատված է։ Մի օգտագործեք այն, որովհետև մեկ ծառայություն դադարեց պատասխանել, քանի որ փոփոխությունը կարող է հյուրին դուրս հանել այն մեկուսացումից, որն անվտանգ էր դարձնում դրա դեմ զարգացումը։

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

VirtualBox-ի host-only ցանցավորման բաժինը նկարագրում է հոսթի կողմի ծրագրային ինտերֆեյսը և ինչով է այն տարբերվում կամրջային միացումից, ինչը հղումն է, որն արժե կարդալ նախքան երկու ռեժիմները փոխարինելի համարելը։