Mitme NIC-iga GCP VM: miks vastused lahkuvad vale liidese kaudu

Teise liidese kinnitamine Compute Engine'i VM-ile annab sellele veel ühe võrguühenduse, mitte sümmeetrilise tagasitee. Külaline valib endiselt liidese ja lähteaadressi oma marsruutide ja reeglite järgi. Seejärel rakendab Google Cloud VPC marsruutimist ja tulemüüri poliitikat selle liidese ümber, mille kaudu pakett väljus. Kui need kaks otsust ei ühti, saabuvad päringud ühte NIC-i ja vastused lahkuvad teise kaudu ning haru näeb pooleldi avatud vestlust.

Käige tee läbi viies sammus ja lahknevus ilmneb enne, kui kirjutate poliitikareegli.

Samm 1: vastendage pilve NIC-id külalise seadmetega

Pilv nimetab liideseid nic0, nic1 ja nii edasi, külaline näeb aga seadmenimesid, mis ei pea ühtima. Selgitage vastendus eksemplari metaandmetest või liidese enda aadressist enne kõike muud. Tavaline DHCP pakutav vaikemarsruut on seotud nic0-ga, mistõttu võidab internetti suunduv tee nii sageli kogemata. Oletatud seadmenime järgi poliitika kirjutamine on viis, kuidas õige reegel satub vale liidese peale.

Märkige üles aadressid, seadmenimed ja VPC, kuhu igaüks kuulub. See kolme veeruga kaart on iga järgneva sammu sisend.

Samm 2: nimetage kaks marsruudiotsust

Esimene otsus kuulub külalisele: milline liides ja milline lähteaadress sellele paketile. Teine kuulub pilvele: mida VPC marsruudid ja tulemüüri poliitika selle liidese ümber lubavad.

VPN-i suunatud VPC-s nähtav marsruut ei muutu külalise marsruudiks, mis selle NIC-i valiks. Pilve marsruut kirjeldab, mida võrk suudab kohale toimetada, samas kui külalise marsruut otsustab, mida pakett teeb.

Samm 3: valige tagasitee poliitika

Väikese ja stabiilse harukontori prefiksite komplekti jaoks on selgesõnalised külalise sihtkoha marsruudid lihtsaim väljendus: nendele prefiksitele suunatud vastused lahkuvad VPN-i suunatud liidese kaudu. Kui mitu teenust kasutavad teadlikult erinevaid kohalikke lähteaadresse, hoiavad allikapõhised reeglid, mis valivad liidese kohta tabeli, iga vastuse õiges kontekstis. Mitme liidese dokumentatsioon kirjeldab NIC-ide nimetamist ja vaikemarsruudi käitumist, millele need lahendused toetuvad.

Iga tabel vajab kehtivaid ühendatud marsruute ja järgmisi hüppeid, lisaks sihtkohti, mille kohta seda küsitakse. Mittetäielikku tabelisse osutav reegel ei ole tagasitee lahendus. Kasutage selle NIC-i jaoks dokumenteeritud lüüsi, selle asemel et alamvõrgu välimuse põhjal Etherneti lüüsi välja mõelda.

Samm 4: kontrollige külalise enda filtreid

Kontrollige, kus server kuulab ja millist kohalikku allikat vastus kannab. Kõiki aadresse kuulav kuulaja ei tühista marsruutimispoliitikat, seega kõikidele aadressidele sidumine ei muuda midagi liidese osas, mille kaudu vastus väljub.

Linuxis vaadake üle pöördtee valideerimine kavandatud lahenduse suhtes. Selle globaalne väljalülitamine esimese sammuna vahetab marsruutimisvea võltsimisele avatuse vastu ja varjab asümmeetria, mida te püüdsite leida.

Samm 5: testige ühte voogu tee kohta

Kontrollige eraldi lubatud harukontori päringut ja mitteseotud internetipäringut, kumbagi oma tegeliku allika ja sihtkohaga. Salvestage mõlemal liidesel, kui saate, sest kasulik tõend on see, milline liides vastuse kandis. Seejärel kinnitage, et pilvepoolne poliitika austas teie kavandatud teed. Üks edukas päring tõestab ühte voogu, mitte sümmeetrilist lahendust.

Hoidke kaks testi märkmetes eraldi, kuna need kasutavad erinevaid marsruute ja erinevaid tulemüürireegleid.

Mida teine NIC teile ei anna

Teine liides lisab võrguühenduse ja veel ühe aadressi. See ei lisa automaatset sümmeetrilist marsruutimist ega möödu tulemüüri poliitikast. Selle kui marsruutimisparanduse käsitlemine on põhjus, miks mitme NIC-iga lahendused koguvad reegleid, mida hiljem keegi seletada ei suuda.

Kui VM peab teiste masinate liiklust edasi suunama, planeerige see ruuteri roll selgesõnaliselt, sealhulgas pilve seade, mis lubab edasisaatmist, ja sellega kaasnevad külalise filtrid.