It tafoegjen fan in twadde ynterface oan in Compute Engine-VM jout it noch in netwurkferbining, gjin symmetryske weromrûte. De gast kiest noch altyd in ynterface en in boarneadres út syn eigen rûtes en regels. Google Cloud past dan VPC-routing en firewallbelied ta om de ynterface dêr't it pakket ferlitten hat. As dy twa besluten net oerienkomme, komme fersiken op ien NIC oan en geane antwurden oer de oare fuort, en de filiaal sjocht in healiepen petear.

Gean it paad yn fiif stappen en de ûnienigens lit him sjen foardat jo in beliedsregel skriuwe.

Stap 1: keppelje cloud-NIC's oan gastapparaten

De cloud neamt ynterfaces nic0, nic1 ensafuorthinne, en de gast sjocht apparaatnammen dy't net oerien hoewe te kommen. Los de keppeling op út 'e metagegevens fan 'e eksimplaar of út it eigen adres fan 'e ynterface foar al it oare. De gewoane standertrûte fan DHCP is keppele oan nic0, en dêrom wint it ynternetpaad sa faak by ûngelok. Belied skriuwe tsjin in rieden apparaatnamme is hoe't in korrekte regel op 'e ferkearde ynterface telâne komt.

Skriuw adressen, apparaatnammen en de VPC dêr't elk by heart op. Dy kaart mei trije kolommen is de ynput foar elke lettere stap.

Stap 2: beneam de twa routingbesluten

It earste beslút heart by de gast: hokker ynterface en hokker boarneadres foar dit pakket. It twadde heart by de cloud: wat de rûtes fan 'e VPC en it firewallbelied om dy ynterface hinne tastean.

In rûte dy't sichtber is yn 'e VPN-rjochte VPC wurdt gjin gastrûte dy't dy NIC kiest. De cloudrûte beskriuwt wat it netwurk leverje kin, wylst de gastrûte beslút wat it pakket docht.

Stap 3: kies in belied foar de weromrûte

Foar in lytse, stabile set filiaalprefiksen binne eksplisite gastbestimmingsrûtes de ienfâldichste útdrukking: antwurden op dy prefiksen geane oer de VPN-rjochte ynterface fuort. As ferskate tsjinsten mei opsetsin ferskillende pleatslike boarneadressen brûke, hâlde boarnebasearre regels dy't in tabel per ynterface kieze elk antwurd yn 'e juste kontekst. De dokumintaasje oer meardere ynterfaces beskriuwt de NIC-nammjouwing en it standertrûtegedrach dêr't dizze ûntwerpen op stypje.

Elke tabel hat jildige ferbûne rûtes en folgjende hops nedich, plus de bestimmings dêr't er om frege wurde sil. In regel dy't yn in ûnfolsleine tabel wiist is gjin weromrûte-ûntwerp. Brûk de dokumintearre gateway foar dy NIC ynstee fan in Ethernet-gateway te betinken út it oansjen fan it subnet.

Stap 4: kontrolearje de eigen filters fan 'e gast

Kontrolearje wêr't de server harket en hokker pleatslik boarne it antwurd draacht. In harker op alle adressen oerhearsket it routingbelied net, dat binen oan alle adressen feroaret neat oan 'e ynterface dêr't it antwurd oer fuortgiet.

Kontrolearje op Linux de falidaasje fan 'e omkearde rûte tsjin it bedoelde ûntwerp. It globaal útskeakeljen as earste stap ruilet in routingflater foar in spoofing-bleatstelling en ferberget de asymmetry dy't jo besochten te finen.

Stap 5: test ien stream per paad

Kontrolearje in tastien filiaalfersyk en in net besibbe ynternetfersyk apart, elk mei syn echte boarne en bestimming. Fange op beide ynterfaces as jo kinne, want it nuttige bewiis is hokker ynterface it antwurd droegen hat. Befêstigje dan dat it belied oan 'e cloudkant it paad dat jo ûntwurpen hawwe, respektearre hat. Ien suksesfol fersyk bewiist ien stream, net in symmetrysk ûntwerp.

Hâld de twa tests apart yn jo notysjes, om't se ferskillende rûtes en ferskillende firewallregels brûke.

Wat in twadde NIC jo net jout

In twadde ynterface foeget in netwurkferbining en noch in adres ta. It foeget gjin automatyske symmetryske routing ta en it omgiet gjin firewallbelied. It behanneljen as in routingreparaasje is wêrom't multi-NIC-ûntwerpen regels opheapje dy't nimmen letter ferklearje kin.

As de VM it ferkear fan oare masines trochstjoere moat, plan dy routerrol eksplisyt, ynklusyf de cloudynstelling dy't trochstjoeren tastiet en de gastfilters dy't dermei geargeane.

Relatearre artikelen