Extensió del lloc VPN: seguiu la ruta de tornada més enllà de la passarel·la

El trànsit d’una branca acaba en una passarel·la la LAN de la qual no conté l’aplicació a què us havien demanat arribar. El servidor és en un segon centre de dades, a l’altre costat d’un enllaç intern que la VPN mai no va configurar. Afegir un altre prefix a la passarel·la propera no fa res per a aquest cas, perquè la passarel·la llunyana és un punt final de xifratge i no l’últim encaminador. El camí necessita una ruta endavant, una admissió a la frontera de seguretat llunyana i una decisió de retorn a la mateixa xarxa de destinació.

La passarel·la llunyana és un punt final de xifratge

L’IPsec de passarel·la a passarel·la protegeix el trànsit entre dos dispositius de seguretat, i les adreces internes viatgen per aquest segment xifrades. Més enllà de la passarel·la llunyana, pren el relleu l’encaminament ordinari, inclosa qualsevol política que existeixi entre centres de dades. El segment protegit, doncs, cobreix una part del trajecte i no la resta. Suposar el contrari és com un disseny acaba amb un túnel sa i una aplicació inabastable.

Dibuixeu el camí en tres trossos: branca a passarel·la propera, propera a llunyana, llunyana a l’aplicació. Cada tros té el seu propietari i el seu mode de fallada.

Llegiu les dues direccions de la política del túnel

La política del túnel s’escriu normalment des de la perspectiva del costat local, i d’aquest hàbit vénen les configuracions parcials. Tots dos parells han de llistar l’origen de la branca i la destinació tal com apareixeran dins del túnel, incloent-hi qualsevol traducció que el disseny pretengui. Actualitzar només l’extrem proper produeix un desajust de fase dos que sembla una fallada d’encaminament. Compareu els dos conjunts de polítiques abans de tocar cap ruta.

Escriviu origen i destinació com a adreces i no com a noms de lloc. L’ambigüitat aquí reapareix més tard com una asimetria desconcertant.

Afegiu la ruta endavant i confirmeu l’admissió

La passarel·la llunyana necessita una ruta cap a la subxarxa de l’aplicació, i cada encaminador entre elles ha d’admetre l’origen de la branca. Verifiqueu què té realment la passarel·la llunyana en lloc del que afirma el diagrama.

ip route get 10.30.5.10 from 10.10.1.50
traceroute -n -s 10.10.1.50 10.30.5.10

La primera ordre informa de la interfície de sortida i del següent salt que la passarel·la llunyana triaria per a aquest origen, una pregunta que una taula d’encaminament simple no pot respondre. El traçat mostra on s’aturen els paquets, i una interrupció després de la passarel·la llunyana apunta al trànsit intern i no al túnel. Quan la ruta existeix i el trànsit encara desapareix, captureu a la passarel·la llunyana i llegiu l’adreça d’origen que arriba, perquè una adreça inesperada vol dir que hi ha traducció en algun lloc no planificat. Totes les adreces d’aquí són marcadors, així que substituïu les subxarxes reals de branca, trànsit i aplicació.

Proveu des de la branca i torneu a provar el camí antic

L’acceptació necessita un origen real i no una sonda des de la passarel·la llunyana. Executeu la comprovació des d’un equip de la branca i manteniu les destinacions que ja funcionaven en la mateixa prova.

curl -sS -m 5 http://10.30.5.10:8080/health
ping -c 3 10.20.1.1

Una resposta de l’aplicació demostra el camí d’anada i el de tornada alhora, mentre que el ping a la destinació antiga demostra que el canvi no ha trencat el que ja funcionava. Captureu l’adreça d’origen que registra l’aplicació, perquè les seves regles d’accés i qualsevol ruta de retorn han de coincidir amb aquest valor. On la branca tradueix abans del túnel, l’adreça de la política i l’adreça que veu l’aplicació difereixen per disseny, així que registreu totes dues. Repetiu la prova després d’una renovació de clau o d’un canvi d’encaminament, perquè aquests camins solen validar-se un cop i després s’obliden.

Assigneu un propietari a cada un dels tres segments i a la ruta de retorn dins de la xarxa de destinació. Un camí amb quatre propietaris falla en els buits entre ells.