EC2 entre zones de disponibilitat: comproveu l'encaminament abans d'una VPN

Abans d'instal·lar programari VPN entre dues instàncies EC2, responeu una pregunta: són a la mateixa VPC? Si ho són, el camí privat ja existeix i la col·locació entre zones no ho canvia. La major part de la feina en aquesta situació és confirmar quina taula d'encaminament fa servir realment cada subxarxa i, després, esbrinar si la fallada havia estat mai un problema d'encaminament. Un túnel sol ser la resposta equivocada a aquesta pregunta concreta.

Comprovació 1: la mateixa VPC o VPC diferents

Una VPC és regional i abasta zones de disponibilitat, mentre que cada subxarxa pertany exactament a una zona. Dues instàncies en zones diferents d'una mateixa VPC segueixen dins del mateix domini d'encaminament privat.

Les VPC diferents no obtenen mai una ruta privada pel fet de compartir una regió o una etiqueta de zona. Aquest cas necessita una connexió admesa i una feina pròpia de rutes i permisos, que és una decisió a part.

Comprovació 2: què diuen les taules d'encaminament de les subxarxes

Escriviu el disseny amb valors reals. Una VPC a 10.60.0.0/16 amb subxarxes 10.60.1.0/24 i 10.60.2.0/24 dona a les instàncies 10.60.1.10 i 10.60.2.20 un camí per la ruta local de la VPC.

Després reviseu les taules associades a les dues subxarxes, no només la que vau trobar primer. Una ruta d'inspecció o d'aparell més específica pot substituir la línia de base, i l'objectiu de la ruta local pot ser reemplaçat en configuracions més noves. Una ruta local visible en algun lloc de la consola no demostra que les dues càrregues de treball la facin servir.

Feu servir les adreces i els noms privats que la VPC assigna realment. Una adreça privada no ha de començar per 10, i inventar-ne una de memòria és com es diagnostica malament un entorn que funciona.

Comprovació 3: encaminament o autorització

L'encaminament només porta el paquet fins a la interfície de xarxa de l'objectiu. El grup de seguretat de l'objectiu encara ha d'admetre l'origen i el servei, les regles de sortida de l'origen han de permetre la petició, i qualsevol ACL de xarxa ha de permetre les dues direccions perquè les ACL no guarden estat.

Més enllà hi ha el tallafoc convidat, l'enllaç de l'oient i la identitat pròpia de l'aplicació. Cadascun pot refusar una petició que l'encaminament ha lliurat perfectament.

L'acceptació ha de ser l'operació real de l'aplicació. Un ping correcte no atorga accés a l'aplicació ni demostra que el nom TLS i les credencials siguin correctes, i un ping bloquejat no estableix que tots els serveis privats estiguin caiguts.

Comprovació 4: cal realment una connexió separada

Una VPN encara pot tenir lloc en el disseny, però per una raó declarada: connectar aquesta VPC a una oficina, admetre portàtils o complir un requisit de superposició. Aquesta raó és diferent de la comunicació normal dins d'una mateixa VPC.

Recordeu també què no és una VPC. No és una extensió d'un segment Ethernet domèstic. Una aplicació que depèn del descobriment per difusió té un requisit a part per avaluar. Això és una llacuna de disseny, no un error d'encaminament.

Comprovació 5: la qüestió del xifratge

Una adreça privada i una regla de permís no diuen res sobre la protecció criptogràfica a la capa d'aplicació. Si les dades necessiten protecció d'extrem a extrem, aquesta ve del protocol i del model d'identitat que el servei admet realment.

Manteniu separades les afirmacions de la capa de xarxa i de la capa d'aplicació a la nota de disseny, perquè fusionar-les és com una revisió acaba afirmant una protecció que ningú no ha implementat.

Què cal enregistrar

Enregistreu els dos identificadors de subxarxa, la taula d'encaminament associada a cadascuna, les referències dels grups de seguretat i l'operació d'aplicació que heu provat. Són quatre fets, i resolen la majoria de discussions futures sobre aquest camí.

La col·locació en una zona per si sola no us diu mai que afegiu una VPN, i no explica mai per què ha fallat una petició privada.