La comprovació d'origen/destinació és una porta, no tot el camí VPN
Una instància de reenviament necessita permís d'AWS, a més de rutes de Linux i regles de tallafoc. Comproveu la validació d'origen/destinació a la instància que reenvia.
La VPN acaba en una instància d'EC2, podeu arribar a l'adreça del túnel d'aquesta instància, i el trànsit que havia de passar-hi cap a un altre amfitrió privat desapareix. Són dues proves diferents, i barrejar-les fa perdre hores. La primera pregunta si podeu arribar a la instància; la segona demana que reenviï trànsit per a una destinació que no és la seva, cosa que necessita reenviament de Linux, una política de tallafoc, una ruta a l'altre costat i un permís a nivell d'AWS que no té res a veure amb el sistema operatiu convidat. Res a la consola no crida l'atenció sobre aquesta diferència. El símptoma sembla una fallada d'encaminament, i normalment no ho és.
Separeu les dues proves abans de canviar res
Arribar a la passarel·la demostra el túnel, la ruta cap a la seva adreça i el grup de seguretat que permet l'intercanvi. El reenviament per a un altre amfitrió no demostra res d'això: fa servir una adreça d'origen diferent, una destinació diferent i una instància en un paper per al qual no es va construir necessàriament. Escriviu les dues proves per separat i anoteu quina falla, perquè la correcció de cadascuna viu en una consola diferent. Una instància de passarel·la creada només per acabar túnels no té cap motiu per reenviar res més, i els seus valors per defecte ho reflecteixen. Per això la segona prova necessita la seva pròpia configuració i no un petit retoc de la primera.
Un ping que funciona cap a la passarel·la i un ping que falla cap a l'amfitrió que hi ha més enllà no és un problema intermitent. És el comportament esperat d'una instància a la qual no s'ha dit que pot reenviar.
Escriviu el camí abans de tocar cap paràmetre
Anoteu el prefix del client, la instància o interfície de xarxa de reenviament, la subxarxa de destinació i la ruta de resposta. Una entrada de la taula de rutes de la VPC que apunta a una instància no configura el sistema operatiu de la instància per reenviar, i un nucli convidat amb el reenviament activat no crea una ruta de la VPC. Els dos extrems d'aquesta relació han d'existir, i s'editen en llocs diferents per persones amb accessos diferents.
Després reviseu el paràmetre de comprovació d'origen/destinació al component de reenviament real, no a cada instància de la VPC. AWS documenta per què una instància que reenvia trànsit per a altres ha de tenir aquesta comprovació desactivada, i també per què el paràmetre és una decisió per instància i no un valor per defecte de tota la VPC.
Quatre fronteres, i la comprovació només és una d'elles
Tracteu el camí com quatre preguntes i responeu-les en ordre. La primera resposta que falla és on és la feina, i cap de les altres no la compensarà.
| Boundary | Question it answers |
|---|---|
| VPC route tables | Do the destinations and replies select the intended gateway? |
| Forwarding instance | Do the AWS check and the guest OS both permit forwarding? |
| Access policy | Do security groups, ACLs and host rules allow the exchange? |
| Destination | Can the service accept that source and return a reply? |
L'ordre importa perquè comprovar-ho és barat: les rutes es veuen en una pàgina, la comprovació és un sol atribut, i l'opinió de la destinació sol ser l'última cosa que algú pregunta.
La traducció canvia quin origen veu la destinació
Un disseny encaminat conserva l'adreça d'origen del client, així que la destinació necessita una ruta de retorn cap al prefix del client. Un disseny traduït presenta en canvi l'adreça de la passarel·la, cosa que elimina aquest requisit i el substitueix per una taula d'estats a la passarel·la. Decidiu segons l'arquitectura que voleu, en lloc d'afegir traducció perquè un exemple no relacionat la va fer servir i semblava funcionar.
Si traduïu, limiteu la regla al prefix del client i a la destinació prevista. Si conserveu, confirmeu que l'altre costat realment coneix la ruta en lloc de suposar que n'aprendrà una.
Proveu des del client original, i després conserveu el canvi
Una sol·licitud generada a la passarel·la pot tenir èxit mentre una sol·licitud reenviada falla, perquè és un origen diferent i un cas de reenviament diferent. Després d'una correcció dirigida, repetiu la prova exacta de client a recurs que va fallar, des del mateix client, i confirmeu que la resposta torna i no només que la sol·licitud ha arribat.
Finalment, poseu el paràmetre a la configuració gestionada de la passarel·la perquè una instància de substitució el rebi. Una prova correcta que depèn d'una excepció manual és una prova que caduca a la propera reconstrucció, i la persona que la va descobrir no hi serà per recordar per què.