AWS Client VPN o un bastió per arribar a una VPC amb peering

Un punt final de Client VPN pot arribar a una VPC que té peering amb la seva VPC associada, i no us cal un bastió per fer-ho legítim. L'elecció que val la pena és on el trànsit canvia de mans: una ruta del punt final que aterra a la subxarxa d'associació i creua la connexió de peering, o un host a la VPC amb peering que tanca la sessió. Tots dos camins funcionen i fallen en llocs diferents, així que la decisió és sobre propietat i auditoria, no sobre què permet AWS. Aquí teniu com trio entre ells i les quatre entrades que fan que el camí encaminat passi.

Dos camins, un punt final, propietaris diferents

Al camí encaminat, el trànsit del client arriba al punt final, es tradueix a l'adreça de la interfície de xarxa de Client VPN a la subxarxa d'associació i surt d'aquesta subxarxa per la connexió de peering d'A a B. La VPC B no tanca cap sessió VPN; veu trànsit ordinari de la VPC A, i per això la seva ruta de retorn apunta a la VPC A, no al pool de clients.

Al camí del bastió, el client arriba primer a un host. Un bastió a A encara deixa l'últim salt creuant la connexió de peering, així que manteniu la feina de peering i afegiu una sessió. Un bastió a B també necessita un camí des del client, i quan aquest camí és la mateixa ruta del punt final teniu el disseny encaminat més un salt. El bastió només estalvia feina quan ja existeix, ja té aprovació, i el que hi ha darrere necessita una frontera de sessió i no una de xarxa.

Quatre entrades fan funcionar el camí encaminat

AWS documenta aquest escenari a la pàgina Client VPN how-it-works, i a la pràctica es redueix a quatre entrades que posseeixen dos o tres equips. Els rangs són il·lustratius; el rang amb peering ha de ser únic i el rang de retorn ha de coincidir amb el vostre pla.

La ruta i el permís són controls separats. Una ruta del punt final correcta sense una regla d'autorització que hi coincideixi no dóna res al client; una regla d'autorització per a una destinació que el punt final no pot encaminar li dóna un forat negre. Tots dos han de nomenar el mateix rang.

La ruta del punt final apunta a una subxarxa de la VPC del mateix punt final, mai a la connexió de peering. Les taules de rutes de la VPC apunten a la connexió de peering, mai a una instància ni a una interfície. Copiar un valor entre les dues es desa sense queixa i no encamina res.

Com que la subxarxa d'associació tradueix l'origen del client, B ha d'encaminar de tornada a la VPC A, no al pool de clients. Enviar el rang del client per la connexió de peering sembla simètric, passa la revisió i falla en silenci perquè B no veu mai un paquet amb origen de client.

Grups de seguretat i l'últim metre de permís

L'encaminament porta els paquets a B; B encara decideix. Per a una connexió de peering activa a la mateixa regió, un grup de seguretat a B pot referenciar el grup aplicat a l'associació de Client VPN, cosa que manté la regla estreta i sobreviu als canvis d'adreça. On una referència de grup no és viable, permeteu el rang de la subxarxa d'associació explícitament en lloc d'ampliar-lo a 0.0.0.0/0, cosa que converteix un error d'encaminament en un temps d'espera sense explicació.

Després comproveu què no toca mai l'encaminament: les ACL de xarxa de les dues subxarxes, la llista d'autoritzats o l'audiència del testimoni de l'aplicació, i el DNS. El peering no copia zones allotjades privades, així que el portàtil pot tenir una ruta que funciona cap a una adreça que no pot resoldre, i una connexió de peering no afegeix confiança a un certificat. Apunteu el punt final a un resolutor que respongui per B i després confirmeu que el nom privat i el certificat coincideixen.

Quan el bastió és la resposta honesta

Mantinc tres desencadenants per triar un bastió a propòsit. La VPC amb peering pertany a un equip que no afegirà una ruta de retorn per al vostre rang o no acceptarà una referència de grup. L'accés s'ha d'aprovar o enregistrar per sessió i l'aplicació no ho pot portar ella mateixa. O l'últim salt ha de quedar dins de B perquè el servei només es resol allà i la seva identitat TLS està fixada a un nom intern.

Res d'això no és una volta a la no-transitivitat del peering. La no-transitivitat limita què poden fer els recursos de B: no poden usar A com a trànsit cap a una tercera VPC amb què A té peering. Mai no va significar que un usuari de VPN no pugui arribar a una VPC amb peering directe, i un bastió construït per esquivar aquesta mala lectura és un host per pedaçar sense motiu.

L'error invers costa més amb el temps: fer passar cada equip pel bastió únic que ja existeix, i després descobrir que el seu grup de seguretat, la taula de rutes i la finestra de pedaç són la dependència de producció. Anoteu quin desencadenant serveix el host i retiroeu-lo quan el desencadenant desaparegui.

Transit Gateway i diverses associacions canvien l'aritmètica

Si el punt final està connectat directament a un Transit Gateway en lloc d'una subxarxa, el model canvia: els clients ja no es tradueixen a una adreça d'interfície en una subxarxa d'associació, i les taules de rutes de la passarel·la han de portar el rang del client més l'adjunció que porta a la VPC amb peering. És més net a escala, però la feina es mou de quatre entrades a les taules de rutes de la passarel·la.

Diverses associacions multipliquen les comprovacions. La ruta del punt final pertany al punt final, però cada subxarxa d'associació necessita una taula de rutes amb un salt següent de peering real. Una sessió pot tenir èxit per una associació mentre una altra no té camí de retorn, així que proveu cada una.

Ordre de verificació que troba el trencament de pressa

Executeu aquestes en ordre; cada pas pot passar mentre el següent falla, i un temps d'espera del client gairebé mai no diu quin s'ha trencat.

1. Resoleu el nom de l'aplicació des del client i comproveu que l'adreça és dins del rang amb peering.
2. Connecteu-vos i llegiu el registre de connexions del punt final per a l'associació que va tancar la sessió.
3. En aquesta subxarxa d'associació, confirmeu que la taula de rutes apunta el rang amb peering a una connexió de peering activa.
4. A la subxarxa de recursos de B, confirmeu una entrada de retorn per al rang de la interfície i regles de grup coincidents.
5. Proveu una operació permesa i un recurs que ha de quedar inabastable; el segon enxampa restes de depuració.
6. Torneu a connectar després de qualsevol canvi de ruta split-tunnel, perquè un túnel en marxa no agafarà un conjunt de rutes nou.

Val la pena memoritzar dos símptomes. Un SYN que arriba a B sense resposta és gairebé sempre la ruta de retorn que falta. Una connexió que es completa i després es reinicia sol ser el grup, l'ACL o l'aplicació. Cap dels dos no apareix al registre del punt final com a causa, així que guardeu les quatre entrades amb un propietari al costat de cada una.

Si no es dóna cap dels tres desencadenants, completeu el camí encaminat i enregistreu aquestes quatre entrades. Si se'n dóna un, manteniu el bastió només per a aquesta frontera i deixeu la ruta del punt final per als serveis que no necessiten una sessió al davant.