VM GCP cu mai multe NIC: de ce răspunsurile pleacă pe interfața greșită

Atașarea unei a doua interfețe la o VM Compute Engine îi dă o altă conexiune de rețea, nu o cale de întoarcere simetrică. Oaspetele alege în continuare o interfață și o adresă sursă din propriile rute și reguli. Google Cloud aplică apoi rutarea VPC și politica de firewall în jurul interfeței prin care a ieșit pachetul. Când aceste două decizii nu coincid, cererile ajung pe o NIC și răspunsurile ies pe cealaltă, iar sucursala vede o conversație pe jumătate deschisă.

Parcurgeți calea în cinci pași și nepotrivirea va apărea înainte de a scrie o regulă de politică.

Pasul 1: mapați NIC-urile din cloud la dispozitivele oaspetelui

Cloudul numește interfețele nic0, nic1 și așa mai departe, iar oaspetele vede nume de dispozitiv care nu trebuie să coincidă. Rezolvați maparea din metadatele instanței sau din adresa proprie a interfeței înainte de orice altceva. Ruta implicită obișnuită oferită de DHCP este asociată cu nic0, de aceea calea spre internet câștigă atât de des din întâmplare. Scrierea politicii după un nume de dispozitiv ghicit este modul în care o regulă corectă ajunge pe interfața greșită.

Notați adresele, numele dispozitivelor și VPC-ul căruia îi aparține fiecare. Acea hartă cu trei coloane este intrarea pentru fiecare pas ulterior.

Pasul 2: numiți cele două decizii de rutare

Prima decizie aparține oaspetelui: ce interfață și ce adresă sursă pentru acest pachet. A doua aparține cloudului: ce permit rutele VPC și politica de firewall în jurul acelei interfețe.

O rută vizibilă în VPC-ul orientat spre VPN nu devine o rută a oaspetelui care ar alege acea NIC. Ruta din cloud descrie ce poate livra rețeaua, în timp ce ruta oaspetelui decide ce face pachetul.

Pasul 3: alegeți o politică de cale de întoarcere

Pentru un set mic și stabil de prefixe de sucursală, rutele explicite de destinație din oaspete sunt cea mai simplă expresie: răspunsurile către acele prefixe ies prin interfața orientată spre VPN. Când mai multe servicii folosesc intenționat adrese sursă locale diferite, regulile bazate pe sursă care aleg un tabel pentru fiecare interfață păstrează fiecare răspuns în contextul corect. Documentația despre mai multe interfețe descrie denumirea NIC-urilor și comportamentul rutei implicite pe care se bazează aceste proiecte.

Fiecare tabel are nevoie de rute conectate valide și următoarele salturi, plus destinațiile despre care va fi întrebat. O regulă care indică un tabel incomplet nu este un proiect de cale de întoarcere. Folosiți gateway-ul documentat pentru acea NIC în loc să inventați un gateway Ethernet din aspectul subrețelei.

Pasul 4: verificați filtrele proprii ale oaspetelui

Verificați unde ascultă serverul și ce sursă locală poartă răspunsul. Un ascultător pe toate adresele nu anulează politica de rutare, așa că legarea la toate adresele nu schimbă nimic în privința interfeței prin care iese răspunsul.

Pe Linux, revizuiți validarea căii inverse față de proiectul dorit. Dezactivarea ei globală ca prim pas schimbă o eroare de rutare cu o expunere la falsificare și ascunde asimetria pe care încercați să o găsiți.

Pasul 5: testați un flux pe cale

Verificați separat o cerere de sucursală permisă și o cerere de internet nelegată, fiecare cu sursa și destinația ei reală. Capturați pe ambele interfețe când puteți, pentru că dovada utilă este ce interfață a dus răspunsul. Apoi confirmați că politica din partea cloudului a respectat calea pe care ați proiectat-o. O cerere reușită dovedește un flux, nu un proiect simetric.

Țineți cele două teste separate în notițele voastre, deoarece folosesc rute diferite și reguli de firewall diferite.

Ce nu vă dă o a doua NIC

O a doua interfață adaugă o conexiune de rețea și încă o adresă. Nu adaugă rutare simetrică automată și nu ocolește politica de firewall. Tratarea ei ca o corecție de rutare este motivul pentru care proiectele cu mai multe NIC acumulează reguli pe care nimeni nu le mai poate explica.

Dacă VM-ul trebuie să redirecționeze traficul altor mașini, planificați explicit acel rol de router, inclusiv setarea din cloud care permite redirecționarea și filtrele oaspetelui care o însoțesc.