strongSwan a EC2: feu que la VPC encamini la càrrega de treball

El túnel està aixecat, la instància de passarel·la pot fer ping a la xarxa remota, i la instància d'aplicació del costat no pot arribar enlloc. No hi ha res trencat. La prova que va funcionar es va originar a l'amfitrió VPN i mai no va preguntar si aquell amfitrió podia portar una adreça d'origen diferent per la mateixa relació IPsec. Aquest runbook tanca aquesta bretxa en quatre passos, en l'ordre que manté visible cada fallada.

Primer escriviu les quatre adreces

Cada pas següent hi fa referència, així que ompliu-les per al vostre compte abans de tocar cap taula d'encaminament.

VPC:             10.60.0.0/16
Gateway subnet:  10.60.1.0/24, gateway ENI address 10.60.1.10
Workload subnet: 10.60.2.0/24, application address 10.60.2.20
Remote network:  10.90.0.0/24

L'exemple assumeix una connexió IPsec basada en polítiques aprovada i funcional, i un flux que preserva l'origen. No és un client d'accés remot amb NAT que manlleva una adreça assignada, i aquesta diferència decideix si els selectors han de canviar.

Pas 1: doneu una ruta a la subxarxa de càrrega

La taula d'encaminament realment associada a la subxarxa de càrrega necessita un camí per al prefix remot que apunti a la interfície de xarxa de la passarel·la. Una ruta de convidat instal·lada dins de la instància no és una entrada en aquella taula d'encaminament d'AWS, i cap quantitat de configuració de strongSwan no en crearà cap.

La guia d'encaminament per aparell d'AWS descriu els destins d'interfície de xarxa i el requisit de comprovació d'origen/destí de la instància que reenvia. Limiteu aquest canvi de comprovació al rol de passarel·la i deixeu les instàncies d'aplicació ordinàries en pau.

No substituïu la ruta local de la VPC ni cada entrada existent per fer lloc a una xarxa aprovada. Inspeccioneu què està associat i actiu, no què mostra una pàgina de consola per a una taula d'encaminament que ningú no fa servir. Dues taules que semblen iguals poden tenir associacions diferents. La que importa és aquella a la qual està enganxada la subxarxa de càrrega.

Pas 2: activeu el reenviament al convidat

sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot

El nucli ha de reenviar i el tallafoc de l'amfitrió ha de permetre el trànsit. Afegiu les regles de reenviament previstes per als prefixos de càrrega i remot en lloc d'acceptar-ho tot, i confirmeu que la subxarxa de passarel·la conserva una ruta de transport utilitzable per al seu propi trànsit.

Els grups de seguretat són on aquest pas sol encallar-se. Un dispositiu intermedi no hereta el comportament de referència de grups de seguretat de la comunicació directa entre instàncies, així que una regla copiada d'un exemple de Client VPN gestionat pot no coincidir mai. Comproveu el grup de seguretat i l'ACL de subxarxa al camí real, en tots dos sentits.

Pas 3: amplieu els selectors als orígens reals

Una política que només cobreix 10.60.1.10/32 al costat d'AWS explica un èxit originat a la passarel·la sense cobrir 10.60.2.20. Una ruta cap al destí remot no amplia un selector de trànsit, i aquesta és la segona meitat de la mateixa sorpresa.

swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors

Si el disseny acordat protegeix tota la VPC, tots dos parells han d'acceptar 10.60.0.0/16 i 10.90.0.0/24. Si protegeix una sola càrrega, feu servir deliberadament aquest prefix més estret. En qualsevol cas, inspeccioneu la política CHILD-SA instal·lada, perquè una configuració que heu editat i un parell que l'ha estretit d'una altra manera no són el mateix acord.

El lloc remot també ha d'encaminar les respostes dels orígens de VPC preservats de tornada a través de la passarel·la IPsec prevista. Manteniu l'exempció de NAT admesa per al trànsit protegit allà on hi hagi altres regles de NAT d'origen; traduir una càrrega no aprovada en una adreça d'amfitrió permesa és un contracte d'identitat diferent, no una drecera cap a l'accés que volíeu.

Pas 4: verifiqueu i, si cal, revertiu

Proveu des de la mateixa càrrega amb una operació d'aplicació permesa nova i després repetiu-ho amb un destí que hauria d'estar exclòs. Anoteu l'adreça d'origen que veu el servei remot i el camí de tornada que utilitza. Un ping a la passarel·la o un estat IKE en verd no és aquesta prova.

Si la càrrega encara falla mentre la passarel·la funciona, retrocediu pels passos en ordre: selector, després reenviament i grups de seguretat, després la taula d'encaminament associada. Cadascun té un símptoma diferent, i endevinar salta el que realment està malament.

La reversió inverteix el mateix ordre. Traieu la ruta de la subxarxa de càrrega al final, després de restaurar els selectors anteriors, per no deixar una subxarxa apuntant a una passarel·la que ja no protegeix els seus orígens. L'autoallotjament pot servir més que l'amfitrió de passarel·la quan aquests contractes es compleixen, i la VPN Site-to-Site gestionada per AWS és un model operatiu diferent on strongSwan pot seure a la banda de la passarel·la de client.