GCP VM kun pluraj NIC-oj: kial respondoj eliras tra la malĝusta interfaco

Aldoni duan interfacon al Compute Engine VM donas al ĝi plian retan konekton, ne simetrian revenan vojon. La gasto ankoraŭ elektas interfacon kaj fontan adreson el siaj propraj itineroj kaj reguloj. Google Cloud poste aplikas VPC-enkursigon kaj fajroŝirmilan politikon ĉirkaŭ tiu interfaco, tra kiu la pako eliris. Kiam tiuj du decidoj malkongruas, petoj alvenas sur unu NIC kaj respondoj eliras tra la alia, kaj la filio vidas duone malfermitan interparolon.

Trapasu la vojon en kvin paŝoj, kaj la malkongruo montriĝos antaŭ ol vi skribos politikan regulon.

Paŝo 1: mapu nubajn NIC-ojn al gastaj aparatoj

La nubo nomas interfacojn nic0, nic1 kaj tiel plu, kaj la gasto vidas aparatajn nomojn, kiuj ne devas kongrui. Solvu la mapadon el la specimenaj metadatumoj aŭ el la propra adreso de la interfaco antaŭ ĉio alia. La ordinara implicita itinero provizita de DHCP estas ligita al nic0, kaj tial la interreta vojo tiel ofte venkas hazarde. Skribi politikon laŭ divenita aparata nomo estas la maniero, kiel ĝusta regulo surteriĝas sur la malĝusta interfaco.

Notu adresojn, aparatajn nomojn kaj la VPC-on, al kiu ĉiu apartenas. Tiu trikolumna mapo estas la enigo por ĉiu posta paŝo.

Paŝo 2: nomu la du enkursigajn decidojn

La unua decido apartenas al la gasto: kiu interfaco kaj kiu fonta adreso por ĉi tiu pako. La dua apartenas al la nubo: kion la itineroj de la VPC kaj la fajroŝirmila politiko permesas ĉirkaŭ tiu interfaco.

Itinero videbla en la VPN-fronta VPC ne fariĝas gasta itinero elektanta tiun NIC. La nuba itinero priskribas, kion la reto povas liveri, dum la gasta itinero decidas, kion faras la pako.

Paŝo 3: elektu politikon de revena vojo

Por malgranda, stabila aro da filiaj prefiksoj, eksplicitaj gastaj celitineroj estas la plej simpla esprimo: respondoj al tiuj prefiksoj eliras tra la VPN-fronta interfaco. Kiam pluraj servoj intence uzas malsamajn lokajn fontadresojn, font-bazitaj reguloj, kiuj elektas tabelon po interfaco, tenas ĉiun respondon en la ĝusta kunteksto. La dokumentaro pri pluraj interfacoj priskribas la NIC-nomadon kaj la implicitan itineran konduton, sur kiuj tiuj dezajnoj dependas.

Ĉiu tabelo bezonas validajn konektitajn itinerojn kaj sekvajn saltetojn, plus la celojn, pri kiuj oni demandos ĝin. Regulo montranta en nekompletan tabelon ne estas revena-voja dezajno. Uzu la dokumentitan kluzon por tiu NIC anstataŭ elpensi Ethernet-kluzon el la aspekto de la subreto.

Paŝo 4: kontrolu la proprajn filtrilojn de la gasto

Kontrolu, kie la servilo aŭskultas kaj kiun lokan fonton la respondo portas. Aŭskultanto sur ĉiuj adresoj ne superregas enkursigan politikon, do ligiĝo al ĉiuj adresoj tute ne ŝanĝas la interfacon, tra kiu la respondo eliras.

En Linux, revizuu la inversvojan validigon kontraŭ la celita dezajno. Globale malŝalti ĝin kiel unuan paŝon interŝanĝas enkursigan cimon kontraŭ trompadan eksponon, kaj kaŝas la malsimetrion, kiun vi klopodis trovi.

Paŝo 5: testu unu fluon po vojo

Kontrolu aparte permesitan filian peton kaj nerilatan interretan peton, ĉiun kun ĝia reala fonto kaj celo. Kaptu sur ambaŭ interfacoj, kiam vi povas, ĉar la utila pruvo estas, kiu interfaco portis la respondon. Poste konfirmu, ke la politiko ĉe la nuba flanko respektis la vojon, kiun vi projektis. Unu sukcesa peto pruvas unu fluon, ne simetrian dezajnon.

Tenu la du testojn aparte en viaj notoj, ĉar ili ekzercas malsamajn itinerojn kaj malsamajn fajroŝirmilajn regulojn.

Kion dua NIC ne donas al vi

Dua interfaco aldonas retan konekton kaj plian adreson. Ĝi ne aldonas aŭtomatan simetrian enkursigon kaj ne preterpasas fajroŝirmilan politikon. Trakti ĝin kiel enkursigan riparon estas la kialo, ke multi-NIC-dezajnoj akumulas regulojn, kiujn poste neniu povas klarigi.

Se la VM devas plusendi la trafikon de aliaj maŝinoj, planu tiun enkursigilan rolon eksplicite, inkluzive de la nuba agordo, kiu permesas plusendadon, kaj la gastaj filtriloj, kiuj akompanas ĝin.