Vagrant VM-ը անհետանում է VPN-ի միանալիս. ում երթուղին կոտրվեց
Մեկ րոպե առաջ պատասխանող մեքենան անհետանում է միացման պահին. որոշեք, թե ում է պատկանում կոտրված երթուղին, նախքան որևէ բան փոխելը.
Մեքենան պատասխանում էր մեկ րոպե առաջ, 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-ին, դուք վերականգնել եք այն ուղին, որով սկսել էիք։ Երբ աշխատում է դրանցից միայն մեկը, մնացած խափանումը գտնվում է մյուս սեփականատիրոջ տարածքում, և տարբերությունը ասում է, թե որ տարածքն է։