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

Հետևեք երթուղուն, ոչ թե մեքենային

Նայեք հոսթի երթուղայնացման որոշմանը հյուրի հասցեի համար, մինչ թունելը բաց է։ Երթուղին, որը դեռ ցույց է տալիս միայն հոսթի ադապտերին, խնդիրը չէ։ Երթուղին, որը հիմա ցույց է տալիս VPN ադապտերին, խնդիրն է, և այն փոխել է հաճախորդը, ոչ դուք։ Այն, որ ադապտերը պահում է իր հասցեն, ասում է, որ ինտերֆեյսը ողջ մնաց, ինչը տարբեր փաստ է ուղու ողջ մնալուց։

SSH սեսիան, որը ընկնում է հենց միացման պահին, սպասելի վարք է։ Հաճախորդը վերամշակում է ադապտերները և տեղադրում երթուղիներ, այդ պատճառով կապը մահանում է մի քանի վայրկյան։ Խափանումը այն կապն է, որը երբեք չի վերադառնում, ոչ թե այն, որը պարզապես թարթեց։

Գրավեք աղյուսակը թունելից առաջ և նորից դրանից հետո, ապա համեմատեք այդ երկու ելքերը։ Տարբերությունը ախտորոշումն է, և այն նաև այն ապացույցն է, որը կպահանջի ցանցի սեփականատերը։

ip -4 route get 192.168.56.10
ip -brief addr show
ip route show table main | head -20

Կարդացեք հոսթի աղյուսակը առաջ և հետո

Linux-ում համընկնող երթուղիների միջև առաջնահերթությունը գալիս է նախածանցի երկարությունից և մետրիկայից, ուստի ավելի կոնկրետ VPN երթուղին հաղթում է նույնիսկ երբ սխալ է։ Windows-ում ինտերֆեյսի մետրիկան որոշում է հավասարությունը, և թունելի ադապտերը սովորաբար գալիս է վիրտուալից ավելի ցածր մետրիկայով։ Երկու դեպքում էլ տեսանելի ախտանիշը նույնն է. փաթեթները դուրս են գալիս թունելի ադապտերով և անհետանում։

Տպեք ադապտերները և դրանց մետրիկաները հյուրի նախածանցի երթուղու կողքին։ Այդ ելքերի զույգը մեկ հայացքով պատասխանում է սեփականության հարցին։

Get-NetAdapter | Select-Object Name, InterfaceIndex, InterfaceMetric
Get-NetRoute -DestinationPrefix 192.168.56.0/24
route print -4 | Select-String '192.168.56'

Եթե երթուղին փոխվել է, բայց ադապտերի մետրիկան՝ ոչ, հաճախորդը տեղադրել է մրցակից երթուղի։ Եթե մետրիկան փոխվել է, հաճախորդը վերադասավորել է ադապտերները։ Երկուսն էլ ուղղելի են, և ուղղվում են տարբեր տեղերում։

Երբ հյուրի NAT միջակայքն է բախումը

VirtualBox NAT-ը լռելյայն օգտագործում է 10.0.2.0/24-ը, և նույն միջակայքը հրող թունելը ստիպում է հյուրին այդ տրաֆիկն ուղարկել իր NAT դարպասին՝ իրական նպատակակետի փոխարեն։ Փաթեթը երբեք չի լքում հոսթը, ուստի մյուս կողմի որևէ firewall մատյան այն չի ցուցադրի։ Docker Machine-ը նույն կարգի հակամարտությունն ունի իր միայն-հոսթ պլանում, և այդ պլանը փոխելը կարող է պահանջել մեքենայի վերստեղծում իր վկայագրերի հետ միասին։

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

Սահմանեք նոր միջակայքը մեքենայի ստեղծման պահին, կամ փոխեք այն և վերսկսեք, ապա նորից փորձարկեք ձախողվող կապը հյուրից։ Հյուրի սեփական աղյուսակն այն տեսքն է, որը կարևոր է։

VBoxManage modifyvm devbox --natnet1 10.77.0.0/24
vagrant reload devbox --provision
vagrant ssh devbox -c 'ip route get 10.20.0.15'

Վերականգնեք ուղին առանց հաճախորդի հետ կռվելու

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

Սկրիպտավորեք ստուգումը՝ գործարկման ժամանակ կույր վերամիացման փոխարեն։ Փոքր սկրիպտը, որը յուրաքանչյուր միացումից հետո տպում է հյուրի նախածանցի երթուղին, առեղծվածը դարձնում է մատյանի տող։

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

Ստուգեք ուղղումը երկու կողմից

Փոփոխությունից հետո ստուգեք երեք ուղի՝ հոսթից հյուր, հյուրից կորպորատիվ հոսթ և հյուրից ինտերնետ։ Ուղղումը, որը վերականգնում է դրանցից մեկը և կոտրում մյուսը, վերանորոգման քողով կարգաբերման փոփոխություն է։ Գրավեք այն նույն ելքերը, որոնք հավաքել էիք փոփոխությունից առաջ, որպեսզի համեմատությունը հավասար լինի հավասարի հետ։

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

ip -4 route get 192.168.56.10
traceroute -n -m 4 10.20.0.15
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

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

Առնչվող հոդվածներ