GCP VM ar vairākiem NIC: kāpēc atbildes iziet pa nepareizo saskarni

Otras saskarnes pievienošana Compute Engine VM dod tai vēl vienu tīkla savienojumu, nevis simetrisku atgriešanās ceļu. Viesis joprojām izvēlas saskarni un avota adresi no saviem maršrutiem un noteikumiem. Pēc tam Google Cloud piemēro VPC maršrutēšanu un ugunsmūra politiku ap to saskarni, pa kuru pakete izgāja. Kad šie divi lēmumi nesakrīt, pieprasījumi ierodas uz vienu NIC, bet atbildes iziet pa otru, un filiāle redz pusatvērtu sarunu.

Izejiet ceļu piecos soļos, un neatbilstība parādīsies pirms politikas noteikuma rakstīšanas.

Solis 1: kartējiet mākoņa NIC uz viesa ierīcēm

Mākonis saskarnes nosauc nic0, nic1 un tā tālāk, un viesis redz ierīču nosaukumus, kuriem nav jāsakrīt. Noskaidrojiet atbilstību no instances metadatiem vai no pašas saskarnes adreses pirms jebkā cita. Parastais DHCP nodrošinātais noklusējuma maršruts ir saistīts ar nic0, tāpēc uz internetu vērstais ceļš tik bieži uzvar nejauši. Politikas rakstīšana pēc minēta ierīces nosaukuma ir veids, kā pareizs noteikums nonāk nepareizajā saskarnē.

Pierakstiet adreses, ierīču nosaukumus un VPC, kuram katrs pieder. Šī trīs kolonnu karte ir katras nākamās darbības ievade.

Solis 2: nosauciet divus maršrutēšanas lēmumus

Pirmais lēmums pieder viesim: kura saskarne un kura avota adrese šai paketei. Otrais pieder mākonim: ko atļauj VPC maršruti un ugunsmūra politika ap šo saskarni.

Maršruts, kas redzams uz VPN vērstajā VPC, nekļūst par viesa maršrutu, kas izvēlas šo NIC. Mākoņa maršruts apraksta, ko tīkls var piegādāt, bet viesa maršruts izlemj, ko dara pakete.

Solis 3: izvēlieties atgriešanās ceļa politiku

Mazam, stabilam filiāles prefiksu kopumam skaidri viesa galamērķa maršruti ir vienkāršākais izteiciens: atbildes uz šiem prefiksiem iziet pa uz VPN vērsto saskarni. Kad vairāki pakalpojumi apzināti izmanto dažādas vietējās avota adreses, avotā balstīti noteikumi, kas izvēlas tabulu katrai saskarnei, saglabā katru atbildi pareizajā kontekstā. Dokumentācija par vairākām saskarnēm apraksta NIC nosaukumus un noklusējuma maršruta uzvedību, uz ko šie projekti paļaujas.

Katrai tabulai ir vajadzīgi derīgi savienotie maršruti un nākamie lēcieni, kā arī galamērķi, par kuriem to jautās. Noteikums, kas norāda uz nepilnīgu tabulu, nav atgriešanās ceļa projekts. Izmantojiet dokumentēto vārteju šim NIC, nevis izgudrojiet Ethernet vārteju pēc apakštīkla izskata.

Solis 4: pārbaudiet paša viesa filtrus

Pārbaudiet, kur serveris klausās un kuru vietējo avotu nes atbilde. Klausītājs visās adresēs neatceļ maršrutēšanas politiku, tāpēc piesaiste visām adresēm neko nemaina attiecībā uz saskarni, pa kuru iziet atbilde.

Linux sistēmā pārskatiet apgrieztā ceļa validāciju pret iecerēto projektu. Tās globāla izslēgšana kā pirmais solis apmaina maršrutēšanas kļūdu pret viltošanas risku un paslēpj asimetriju, ko mēģinājāt atrast.

Solis 5: pārbaudiet vienu plūsmu katram ceļam

Pārbaudiet atsevišķi atļauto filiāles pieprasījumu un nesaistīto interneta pieprasījumu, katru ar tā reālo avotu un galamērķi. Kad varat, tveriet abās saskarnēs, jo noderīgais pierādījums ir tas, kura saskarne nesa atbildi. Pēc tam apstipriniet, ka mākoņa puses politika ievēroja jūsu projektēto ceļu. Viens veiksmīgs pieprasījums pierāda vienu plūsmu, nevis simetrisku projektu.

Turiet divus testus atsevišķi savos pierakstos, jo tie izmanto dažādus maršrutus un dažādus ugunsmūra noteikumus.

Ko otrs NIC jums nedod

Otra saskarne pievieno tīkla savienojumu un vēl vienu adresi. Tā nepievieno automātisku simetrisku maršrutēšanu un neapiet ugunsmūra politiku. Uzskatīšana par maršrutēšanas labojumu ir iemesls, kāpēc daudzu NIC projektu risinājumi uzkrāj noteikumus, kurus vēlāk neviens nevar izskaidrot.

Ja VM ir jāpārsūta citu mašīnu trafiks, plānojiet šo maršrutētāja lomu skaidri, tostarp mākoņa iestatījumu, kas atļauj pārsūtīšanu, un ar to saistītos viesa filtrus.