GCP-VM met veelvuldige NIC's: waarom antwoorde deur die verkeerde koppelvlak vertrek

Om ’n tweede koppelvlak aan ’n Compute Engine-VM te heg, gee dit nog ’n netwerkkoppeling, nie ’n simmetriese terugpad nie. Die gas kies steeds ’n koppelvlak en ’n bronadres uit sy eie roetes en reëls. Google Cloud pas dan VPC-roetering en brandmuurbeleid toe rondom watter koppelvlak die pakket ook al verlaat het. Wanneer daardie twee besluite verskil, kom versoeke by een NIC aan en verlaat antwoorde deur die ander, en die tak sien ’n halfoop gesprek.

Volg die pad in vyf stappe en die verskil wys sig voordat jy ’n beleidsreël skryf.

Stap 1: karteer wolk-NIC's na gastoestelle

Cloud noem koppelvlakke nic0, nic1 en so meer, en die gas sien toestelname wat nie hoef te ooreenstem nie. Bepaal die kartering uit instansiemetadata of uit die koppelvlak se eie adres voordat jy enigiets anders doen. Die gewone DHCP-verskafte verstekroete word met nic0 geassosieer, en daarom wen die internetgerigte pad so dikwels per ongeluk. Om beleid teen ’n geraakte toestelnaam te skryf, is hoe ’n korrekte reël op die verkeerde koppelvlak beland.

Teken adresse, toestelname en die VPC waaraan elkeen behoort aan. Daardie driekolomkaart is die inset vir elke latere stap.

Stap 2: benoem die twee roetebesluite

Die eerste besluit behoort aan die gas: watter koppelvlak en watter bronadres vir hierdie pakket. Die tweede behoort aan die wolk: wat die VPC se roetes en brandmuurbeleid rondom daardie koppelvlak toelaat.

’n Roete wat in die VPN-gerigte VPC sigbaar is, word nie ’n gasroete wat daardie NIC kies nie. Die wolkroete beskryf wat die netwerk kan lewer, terwyl die gasroete besluit wat die pakket doen.

Stap 3: kies ’n terugpadbeleid

Vir ’n klein, stabiele stel takvoorvoegsels is eksplisiete gasbestemmingsroetes die eenvoudigste uitdrukking: antwoorde op daardie voorvoegsels verlaat deur die VPN-gerigte koppelvlak. Wanneer verskeie dienste doelbewus verskillende plaaslike bronadresse gebruik, hou brongebaseerde reëls wat ’n tabel per koppelvlak kies, elke antwoord in die regte konteks. Die dokumentasie oor veelvuldige koppelvlakke beskryf die NIC-naamgewing en verstekroetegedrag waarop hierdie ontwerpe staatmaak.

Elke tabel benodig geldige gekoppelde roetes en volgende spronge, plus die bestemmings waarvoor daar gevra sal word. ’n Reël wat na ’n onvolledige tabel wys, is nie ’n terugpadontwerp nie. Gebruik die gedokumenteerde poort vir daardie NIC in plaas daarvan om ’n Ethernet-poort uit die subnet se voorkoms te bedink.

Stap 4: kontroleer die gas se eie filters

Kontroleer waar die bediener luister en watter plaaslike bron die antwoord dra. ’n Jokerteken-luisteraar oorheers nie roeteringsbeleid nie, so om aan alle adresse te bind verander niks aan die koppelvlak waardeur die antwoord vertrek nie.

Kontroleer op Linux die validering van die omgekeerde pad teen die beoogde ontwerp. Om dit globaal as eerste stap te deaktiveer, ruil ’n roeteringsfout vir ’n spoofing-blootstelling, en dit verberg die asimmetrie wat jy probeer vind het.

Stap 5: toets een vloei per pad

Verifieer ’n toegelate takversoek en ’n onverwante internetversoek afsonderlik, elkeen met sy werklike bron en bestemming. Vang op albei koppelvlakke vas wanneer jy kan, want die nuttige bewys is watter koppelvlak die antwoord gedra het. Bevestig dan dat die wolkbeleid die pad wat jy ontwerp het, geëerbiedig het. Een suksesvolle versoek bewys een vloei, nie ’n simmetriese ontwerp nie.

Hou die twee toetse apart in jou notas, want hulle oefen verskillende roetes en verskillende brandmuurreëls.

Wat ’n tweede NIC jou nie gee nie

’n Tweede koppelvlak voeg ’n netwerkkoppeling en nog ’n adres by. Dit voeg nie outomatiese simmetriese roetering by nie en dit omseil nie brandmuurbeleid nie. Om dit as ’n roeteringsoplossing te behandel, is waarom multi-NIC-ontwerpe reëls ophoop wat niemand later kan verduidelik nie.

As die VM ander masjiene se verkeer moet aanstuur, beplan daardie roetertaak eksplisiet, insluitend die wolkinstelling wat aanstuur toelaat en die gasfilters wat daarmee saamgaan.