GCP-vél með mörgum NIC: hvers vegna svör fara út um rangt viðmót

Að tengja annað viðmót við Compute Engine-vél gefur henni aðra nettengingarleið, ekki samhverfa endurkomuleið. Gesturinn velur enn viðmót og upprunatölu úr eigin leiðum og reglum. Google Cloud beitir síðan VPC-leiðsögn og eldveggsstefnu í kringum það viðmót sem pakkinn fór út um. Þegar þessar tvær ákvarðanir eru ósammála berast fyrirspurnir á eitt NIC og svör fara út um hitt, og útibúið sér hálfopna samræðu.

Farðu leiðina í fimm skrefum og misræmið kemur í ljós áður en þú skrifar stefnureglu.

Skref 1: varpaðu NIC-um skýsins á tæki gestanna

Skýið nefnir viðmót nic0, nic1 og svo framvegis, og gesturinn sér tækjanöfn sem þurfa ekki að passa. Leystu varpinu úr lýsigögnum tilviksins eða úr eigin tölu viðmótsins áður en nokkuð annað er gert. Venjulega sjálfgefna leiðin sem DHCP veitir er tengd nic0, og þess vegna vinnur internetleiðin svo oft fyrir slysni. Að skrifa stefnu út frá giskguðu tækjanafni er leiðin sem rétt regla lendir á röngu viðmóti.

Skráðu tölur, tækjanöfn og það VPC sem hvert tilheyrir. Það þriggja dálka kort er inntak fyrir hvert síðara skref.

Skref 2: nefndu tvær leiðsagnarákvarðanirnar

Fyrsta ákvörðunin tilheyrir gestinum: hvaða viðmót og hvaða upprunatala fyrir þennan pakka. Önnur tilheyrir skýinu: hvað leiðir VPC og eldveggsstefna leyfa í kringum það viðmót.

Leið sem er sýnileg í VPC sem snýr að VPN verður ekki gestaleið sem velur það NIC. Skýjaleiðin lýsir því sem netið getur afhent, en gestaleiðin ákveður hvað pakkinn gerir.

Skref 3: veldu stefnu fyrir endurkomuleið

Fyrir lítinn, stöðugan hóp útibúsforskeyta eru skýrar áfangaleiðir í gestinum einfaldasta tjáningin: svör við þessum forskeytum fara út um viðmótið sem snýr að VPN. Þegar nokkrar þjónustur nota viljandi mismunandi staðbundnar upprunatölur halda upprunamiðuðum reglum sem velja töflu fyrir hvert viðmót hverju svari í réttu samhengi. Skjöl um mörg viðmót lýsa NIC-nafnasetningu og hegðun sjálfgefinnar leiðar sem þessar hönnur byggja á.

Hver tafla þarf gildar tengdar leiðir og næstu hopp, auk áfanganna sem spurt verður um. Regla sem bendir inn í ófullkomna töflu er ekki hönnun endurkomuleiðar. Notaðu skjalfesta gátt fyrir það NIC í stað þess að búa til Ethernet-gátt út frá útliti undirnetsins.

Skref 4: athugaðu eigin síur gestanna

Athugaðu hvar þjónninn hlustar og hvaða staðbundna uppruna svarið ber. Hlustandi á öllum tölum hnekkir ekki leiðsagnarstefnu, svo að bindast öllum tölum breytir engu um það viðmót sem svarið fer út um.

Á Linux, farðu yfir staðfestingu öfugrar leiðar gegn fyrirhugaðri hönnun. Að slökkva á henni almennt sem fyrsta skref skiptir leiðsagnarbug á móti skúffunaráhættu og felur ósamhverfuna sem þú reyndir að finna.

Skref 5: prófaðu eitt flæði fyrir hverja leið

Staðfestu leyfða útibúsfyrirspurn og ótengda internetfyrirspurn hvor í sínu lagi, hver með raunverulegum uppruna og áfanga. Náðu á báðum viðmótum þegar þú getur, því gagnlegar sannanir eru hvaða viðmót bar svarið. Staðfestu síðan að stefnan á skýjuhliðinni virti leiðina sem þú hannaðir. Ein vel heppnuð fyrirspurn sannar eitt flæði, ekki samhverfa hönnun.

Haltu prófununum tveimur aðskildum í athugasemdunum þínum, þar sem þær nota mismunandi leiðir og mismunandi eldveggsreglur.

Hvað annað NIC gefur þér ekki

Annað viðmót bætir við nettengingu og annarri tölu. Það bætir ekki við sjálfvirkri samhverfri leiðsögn og fer ekki fram hjá eldveggsstefnu. Að líta á það sem leiðsagnarviðgerð er ástæðan fyrir því að hönnur með mörgum NIC safna reglum sem enginn getur útskýrt síðar.

Ef vélin verður að senda umferð annarra véla áfram skal skipuleggja það hlutverk beinlínis, þar á meðal skýjastillinguna sem leyfir sendingu áfram og gestasíurnar sem fylgja henni.