EC2 între zone de disponibilitate: verificați rutarea înainte de un VPN

Înainte de a instala software VPN între două instanțe EC2, răspundeți la o întrebare: sunt în același VPC? Dacă da, calea privată există deja, iar plasarea între zone nu schimbă acest lucru. Cea mai mare parte a muncii în această situație este să confirmați ce tabelă de rutare folosește de fapt fiecare subrețea, apoi să aflați dacă defecțiunea a fost vreodată o problemă de rutare. Un tunel este de obicei răspunsul greșit la această întrebare specifică.

Verificarea 1: același VPC sau VPC-uri diferite

Un VPC este regional și cuprinde zone de disponibilitate, în timp ce fiecare subrețea aparține exact unei zone. Două instanțe din zone diferite ale unui VPC sunt încă în același domeniu de rutare privată.

VPC-urile diferite nu obțin niciodată o rută privată doar pentru că împart o regiune sau o etichetă de zonă. Acel caz necesită o conexiune acceptată și muncă proprie la rute și permisiuni, ceea ce este o decizie separată.

Verificarea 2: ce spun tabelele de rutare ale subrețelelor

Scrieți configurația cu valori reale. Un VPC la 10.60.0.0/16 cu subrețelele 10.60.1.0/24 și 10.60.2.0/24 oferă instanțelor 10.60.1.10 și 10.60.2.20 o cale prin ruta locală a VPC-ului.

Apoi examinați tabelele asociate ambelor subrețele, nu doar pe cea pe care ați găsit-o prima. O rută de inspecție sau de dispozitiv mai specifică poate suprascrie ruta de bază, iar destinația rutei locale poate fi ea însăși înlocuită în configurații mai noi. O rută locală vizibilă undeva în consolă nu dovedește că ambele sarcini de lucru o folosesc.

Folosiți adresele și numele private pe care VPC-ul le alocă de fapt. O adresă privată nu trebuie să înceapă cu 10, iar inventarea uneia din memorie este modul în care un mediu funcțional este diagnosticat greșit.

Verificarea 3: rutare sau autorizare

Rutarea duce doar pachetul până la interfața de rețea a destinației. Grupul de securitate al destinației trebuie încă să admită sursa și serviciul, regulile de ieșire ale sursei trebuie să permită cererea, iar orice ACL de rețea trebuie să permită ambele direcții, deoarece ACL-urile nu păstrează starea.

În spate se află firewall-ul invitatului, legarea ascultătorului și identitatea aplicației în sine. Oricare dintre ele poate refuza o cerere pe care rutarea a livrat-o perfect.

Acceptarea trebuie să fie operația reală a aplicației. Un ping reușit nu acordă acces la aplicație și nu dovedește că numele TLS și credențialele sunt corecte, iar un ping blocat nu stabilește că fiecare serviciu privat este oprit.

Verificarea 4: este într-adevăr necesară o conexiune separată

Un VPN poate face în continuare parte din proiect, dar dintr-un motiv declarat: conectarea acestui VPC la un birou, admiterea laptopurilor sau îndeplinirea unei cerințe de suprapunere. Acel motiv este diferit de comunicarea obișnuită în interiorul aceluiași VPC.

Amintiți-vă și ce nu este un VPC. Nu este o extensie a unui segment Ethernet casnic. O aplicație care depinde de descoperirea prin difuzare are o cerință separată de evaluat. Aceasta este o lacună de proiectare, nu o eroare de rutare.

Verificarea 5: întrebarea despre criptare

O adresă privată și o regulă de permisiune nu spun nimic despre protecția criptografică la nivelul aplicației. Dacă datele au nevoie de protecție de la un capăt la altul, aceasta vine din protocolul și modelul de identitate pe care serviciul le acceptă de fapt.

Țineți separate afirmațiile despre nivelul de rețea și nivelul aplicației în nota de proiectare, pentru că unirea lor este modul în care o revizuire ajunge să afirme o protecție pe care nimeni nu a implementat-o.

Ce trebuie consemnat

Consemnați ambii identificatori de subrețea, tabela de rutare asociată fiecăreia, referințele grupurilor de securitate și operația de aplicație pe care ați testat-o. Sunt patru fapte și rezolvă majoritatea discuțiilor viitoare despre această cale.

Plasarea într-o zonă singură nu vă spune niciodată să adăugați un VPN și nu explică niciodată de ce o cerere privată a eșuat.