GCP վիրտուալ մեքենա մի քանի NIC-ով. ինչու են պատասխանները դուրս գալիս սխալ ինտերֆեյսով

Երկրորդ ինտերֆեյսը Compute Engine վիրտուալ մեքենային ավելացնելը տալիս է ևս մեկ ցանցային միացում, ոչ սիմետրիկ վերադարձի ուղի։ Հյուրը շարունակում է ինտերֆեյսը և աղբյուրի հասցեն ընտրել իր իսկ երթուղիներից ու կանոններից։ Այնուհետև Google Cloud-ը կիրառում է VPC երթուղավորում և firewall քաղաքականություն այն ինտերֆեյսի շուրջ, որով փաթեթը դուրս է եկել։ Երբ այս երկու որոշումները չեն համընկնում, հարցումները հասնում են մի NIC-ի, իսկ պատասխանները դուրս են գալիս մյուսով, և մասնաճյուղը տեսնում է կիսաբաց զրույց։

Անցեք ուղին հինգ քայլով, և անհամապատասխանությունը կերևա նախքան քաղաքականության կանոն գրելը։

Քայլ 1. քարտեզագրեք ամպի NIC-երը հյուրի սարքերին

Ամպը ինտերֆեյսներին անվանում է nic0, nic1 և այլն, իսկ հյուրը տեսնում է սարքերի անուններ, որոնք պարտադիր չէ, որ համընկնեն։ Պարզեք համապատասխանությունը օրինակի մետատվյալներից կամ ինտերֆեյսի սեփական հասցեից ամեն ինչից առաջ։ DHCP-ի տրամադրած սովորական լռելյայն երթուղին կապված է nic0-ի հետ, դրա համար էլ դեպի ինտերնետ ուղին այդքան հաճախ պատահաբար հաղթում է։ Գուշակված սարքի անվան հիման վրա քաղաքականություն գրելը հենց այն ձևն է, որով ճիշտ կանոնը հայտնվում է սխալ ինտերֆեյսի վրա։

Գրանցեք հասցեները, սարքերի անունները և այն VPC-ն, որին պատկանում է յուրաքանչյուրը։ Այդ երեք սյունակով քարտեզը յուրաքանչյուր հաջորդ քայլի մուտքն է։

Քայլ 2. անվանեք երկու երթուղային որոշումները

Առաջին որոշումը հյուրինն է. որ ինտերֆեյսը և որ աղբյուրի հասցեն այս փաթեթի համար։ Երկրորդը ամպինն է. ինչ են թույլատրում VPC-ի երթուղիները և firewall քաղաքականությունը այդ ինտերֆեյսի շուրջ։

VPN-ին ուղղված VPC-ում տեսանելի երթուղին չի դառնում հյուրի երթուղի, որը կընտրի այդ NIC-ը։ Ամպի երթուղին նկարագրում է, թե ցանցը ինչ կարող է հասցնել, մինչդեռ հյուրի երթուղին որոշում է, թե փաթեթն ինչ է անում։

Քայլ 3. ընտրեք վերադարձի ուղու քաղաքականություն

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

Յուրաքանչյուր աղյուսակի պետք են վավեր միացված երթուղիներ և հաջորդ ցատկեր, ինչպես նաև այն նպատակակետերը, որոնց մասին այն կհարցվի։ Թերի աղյուսակին ուղղվող կանոնը վերադարձի ուղու նախագիծ չէ։ Օգտագործեք այդ NIC-ի փաստաթղթավորված դարպասը՝ ենթացանցի տեսքից Ethernet դարպաս հորինելու փոխարեն։

Քայլ 4. ստուգեք հյուրի սեփական զտիչները

Ստուգեք, թե որտեղ է լսում սերվերը և որ տեղական աղբյուրն է կրում պատասխանը։ Բոլոր հասցեներին լսող ընդունիչը չի վերացնում երթուղային քաղաքականությունը, ուստի բոլոր հասցեներին կապվելը ոչինչ չի փոխում այն ինտերֆեյսի հարցում, որով դուրս է գալիս պատասխանը։

Linux-ում վերանայեք հակառակ ուղու վավերացումը նախատեսված նախագծի դեմ։ Այն գլոբալ անջատելը որպես առաջին քայլ երթուղային սխալը փոխանակում է կեղծարարության ենթարկվածության հետ և թաքցնում է անհամաչափությունը, որը փորձում էիք գտնել։

Քայլ 5. փորձարկեք մեկ հոսք յուրաքանչյուր ուղու համար

Ստուգեք առանձին թույլատրված մասնաճյուղի հարցումը և չառնչվող ինտերնետ հարցումը, յուրաքանչյուրն իր իրական աղբյուրով և նպատակակետով։ Երբ կարող եք, գրավեք երկու ինտերֆեյսների վրա, որովհետև օգտակար ապացույցն այն է, թե որ ինտերֆեյսն է տարել պատասխանը։ Այնուհետև հաստատեք, որ ամպի կողմի քաղաքականությունը հարգել է ձեր նախագծած ուղին։ Մեկ հաջող հարցումը ապացուցում է մեկ հոսք, ոչ թե սիմետրիկ նախագիծ։

Ձեր նշումներում երկու փորձարկումները առանձին պահեք, քանի որ դրանք օգտագործում են տարբեր երթուղիներ և տարբեր firewall կանոններ։

Ինչ չի տալիս երկրորդ NIC-ը

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

Եթե վիրտուալ մեքենան պետք է փոխանցի այլ մեքենաների թրաֆիկը, այդ երթուղիչի դերը պլանավորեք հստակ, ներառյալ ամպի այն կարգավորումը, որը թույլատրում է փոխանցումը, և դրան ուղեկցող հյուրի զտիչները։