VM de GCP amb diverses NIC: per què les respostes surten per la interfície equivocada

Adjuntar una segona interfície a una VM de Compute Engine li dona un altre enllaç de xarxa, no un camí de retorn simètric. El convidat continua triant una interfície i una adreça d’origen a partir de les seves pròpies rutes i regles. Google Cloud després aplica l’encaminament de VPC i la política del tallafoc al voltant de la interfície per la qual ha sortit el paquet. Quan aquestes dues decisions no coincideixen, les peticions arriben per una NIC i les respostes surten per l’altra, i la branca veu una conversa mig oberta.

Recorreu el camí en cinc passos i la discrepància apareixerà abans que escriviu una regla de política.

Pas 1: assigneu les NIC del núvol als dispositius del convidat

El núvol anomena les interfícies nic0, nic1 i així successivament, i el convidat veu noms de dispositiu que no cal que coincideixin. Resoleu la correspondència a partir de les metadades de la instància o de l’adreça pròpia de la interfície abans que res. La ruta per defecte habitual que proporciona DHCP s’associa amb nic0, i per això el camí cap a internet sovint guanya per accident. Escriure política contra un nom de dispositiu suposat és com una regla correcta acaba a la interfície equivocada.

Anoteu les adreces, els noms de dispositiu i la VPC a la qual pertany cadascun. Aquest mapa de tres columnes és l’entrada de cada pas posterior.

Pas 2: anomeneu les dues decisions d’encaminament

La primera decisió pertany al convidat: quina interfície i quina adreça d’origen per a aquest paquet. La segona pertany al núvol: què permeten les rutes de la VPC i la política del tallafoc al voltant d’aquesta interfície.

Una ruta visible a la VPC orientada a la VPN no es converteix en una ruta del convidat que triï aquesta NIC. La ruta del núvol descriu què pot lliurar la xarxa, mentre que la ruta del convidat decideix què fa el paquet.

Pas 3: trieu una política de camí de retorn

Per a un conjunt petit i estable de prefixos de branca, les rutes de destinació explícites al convidat són l’expressió més simple: les respostes a aquests prefixos surten per la interfície orientada a la VPN. Quan diversos serveis utilitzen intencionadament adreces d’origen locals diferents, les regles basades en l’origen que trien una taula per interfície mantenen cada resposta en el context correcte. La documentació sobre múltiples interfícies descriu l’anomenament de les NIC i el comportament de la ruta per defecte en què es basen aquests dissenys.

Cada taula necessita rutes connectades vàlides i salts següents, a més de les destinacions que se li demanaran. Una regla que apunta a una taula incompleta no és un disseny de camí de retorn. Utilitzeu la passarel·la documentada per a aquesta NIC en lloc d’inventar una passarel·la Ethernet a partir de l’aspecte de la subxarxa.

Pas 4: reviseu els filtres propis del convidat

Comproveu on escolta el servidor i quin origen local porta la resposta. Un receptor comodí no anul·la la política d’encaminament, així que enllaçar-se a totes les adreces no canvia res sobre la interfície per la qual surt la resposta.

A Linux, reviseu la validació del camí invers respecte del disseny previst. Desactivar-la globalment com a primer moviment canvia un error d’encaminament per una exposició a la suplantació, i amaga l’asimetria que intentàveu trobar.

Pas 5: proveu un flux per camí

Verifiqueu per separat una petició de branca permesa i una petició d’internet no relacionada, cadascuna amb el seu origen i destinació reals. Captureu a les dues interfícies quan pugueu, perquè l’evidència útil és quina interfície va portar la resposta. Després confirmeu que la política del costat del núvol ha respectat el camí que heu dissenyat. Una petició correcta demostra un flux, no un disseny simètric.

Manteniu les dues proves separades a les vostres notes, ja que exerceixen rutes diferents i regles de tallafoc diferents.

Què no us dona una segona NIC

Una segona interfície afegeix un enllaç de xarxa i una altra adreça. No afegeix encaminament simètric automàtic ni evita la política del tallafoc. Tractar-la com una solució d’encaminament és la raó per la qual els dissenys amb diverses NIC acumulen regles que després ningú no pot explicar.

Si la VM ha de reenviar el trànsit d’altres màquines, planifiqueu aquest paper de router explícitament, incloent-hi el paràmetre del núvol que permet el reenviament i els filtres del convidat que hi van associats.