Ձեր VM-ն օգտագործո՞ւմ է հոսթի VPN-ը: Ստուգեք հյուրի ներսից

Հոսթի ելքի հասցեն ոչինչ չի ասում հյուրի երթուղիների մասին: Գրանցեք ցանցի ռեժիմը, ստուգեք հյուրի երթուղին և լուծիչը, ապա ստուգեք ձախողման դեպքը:

Դուք ստուգում եք հոսթի հանրային IP-ն, այն ցույց է տալիս VPN-ը, և եզրակացնում եք, որ VM-ը ծածկված է: Այս եզրակացությունը ստուգումը չի հիմնավորում: Հյուրն ունի իր երթուղավորման աղյուսակը, իր լուծիչը և իր ինտերֆեյսները, և հոսթի ելքի հասցեն ոչինչ չի ասում դրանց մասին:

Ստուգումը պետք է կատարվի հյուրի ներսում և պետք է նշի, թե ինչ է չափել:

Սկսեք հյուրի ներսում, ոչ թե հոսթի զննարկիչում

Նախ գրանցեք հիպերվիզորի ցանցի ռեժիմը՝ NAT, bridged, host-only կամ macvtap: NAT ռեժիմում հոսթը երթուղավորում է հյուրի երթևեկությունը, ուստի հոսթի թունելը կարող է գործել կամ չգործել՝ կախված նրանից, թե ինչպես է հաճախորդը տեղադրում երթուղիները: bridged ռեժիմում հյուրը հավասար մասնակից է ֆիզիկական LAN-ում, և հոսթի թունելը նշանակություն չունի: Այս երկու ռեժիմները տալիս են հակառակ պատասխաններ նույն հոսթի կազմաձևից:

Գրանցեք ռեժիմը նախքան որևէ բան փոխելը, որովհետև այն որոշում է, թե ինչ կարող է նշանակել արդյունքը:

Կատարեք մեկ հարցում, որի նպատակակետը գիտեք

Օգտագործեք անվնաս հարցում դեպի ծառայություն, որը հաղորդում է տեսած աղբյուրի հասցեն: Այնուհետև ստուգեք հյուրի սեփական երթուղային որոշումը այդ նպատակակետի համար՝ ip route get 203.0.113.5 տպում է ինտերֆեյսը և դարպասը, որը հյուրը կօգտագործի:

Եթե ինտերֆեյսը հյուրի սովորական NIC-ն է, երթևեկությունը չի անցնում հյուրի ներսի թունելով:

Երկրորդ ադապտերը, պրոքսիի կարգավորումը կամ հյուրի կողմի VPN հաճախորդը կարող են փոխել պատասխանը մեկ հավելվածի համար և ոչ մյուսի: Ստուգեք այն հավելվածը, որն իսկապես կարևոր է ձեզ, ոչ թե shell-ից արված ընդհանուր հարցում:

Ստուգեք լուծիչը առանձին

Փոխված ելքի հասցեն չի ասում, թե որ լուծիչն է զբաղվել հոսթի անունով: Հարցրեք անունը բացահայտ՝ հարթակին համապատասխան գործիքով, և նշեք, թե որ սերվերն է պատասխանել: Բաժանված DNS-ը նշանակում է, որ լուծիչի հարցն ու երթուղավորման հարցը տարբեր պատասխաններ ունեն:

Այս երկուսը կարող են տարբերվել ցանկացած ուղղությամբ, և տարբերությունը հաճախ հենց իրական սխալն է:

systemd հոսթի վրա resolvectl query նշում է ինտերֆեյսը և պատասխանի հետևում գտնվող DNS սերվերը: Հին կարգավորումները սերվերը ցույց են տալիս dig -ի ելքում — ամեն դեպքում նպատակն այն է տեսնել, թե որ սերվերն է պատասխանել, ոչ միայն այն, թե արդյոք պատասխան է եկել:

Ստուգեք ձախողման քաղաքականությունը, ոչ միայն հաջողությունը

Եթե պահանջն այն է, որ ոչ մի երթևեկություն չդուրս գա թունելից դուրս, հաջող հարցումը ոչինչ չի ապացուցում: Օգտագործեք հաճախորդի աջակցվող վերահսկվող ձախողման ստուգումը՝ կանգնեցրեք թունելը աջակցվող եղանակով և տեսեք՝ արգելափակվում է արդյոք հյուրի նոր հարցումը: Մի ենթադրեք, որ հոսթի հաճախորդի kill switch-ը ծածկում է յուրաքանչյուր վիրտուալ փոխանցման դասավորություն: Միայն նրա փաստաթղթավորված շրջանակն է, որի վրա կարող եք հույս դնել:

Հյուրը, որը թունելի անկման ժամանակ վերադառնում է ֆիզիկական NIC-ին, անում է հենց այն, ինչ թույլ է տալիս NAT ռեժիմը:

Գրանցեք ռեժիմը և շրջանակը

Գրանցեք հիպերվիզորի ռեժիմը, հյուրի ինտերֆեյսը և երթուղին, լուծիչը և այն հավելվածը, որը ստուգել եք: Ավելացրեք ամսաթիվը, որովհետև snapshot-ի վերականգնումը կամ հիպերվիզորի թարմացումը կարող են փոխել բոլոր չորսը:

Եթե IPv4-ը հետևել է թունելին, ասեք դա: Մի ընդլայնեք պնդումը IPv6-ի, այլ անվանատարածքի կամ այլ ցանցում գտնվող այլ VM-ի վրա:

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