EC2 tarp pasiekiamumo zonų: prieš VPN patikrinkite maršrutizavimą

Prieš diegdami VPN programinę įrangą tarp dviejų EC2 egzempliorių, atsakykite į vieną klausimą: ar jie tame pačiame VPC? Jei taip, privatus kelias jau egzistuoja, o išdėstymas skirtingose zonose to nekeičia. Didžioji dalis darbo šioje situacijoje yra patvirtinti, kurią maršrutizavimo lentelę kiekvienas potinklis iš tikrųjų naudoja, ir tada išsiaiškinti, ar gedimas apskritai buvo maršrutizavimo problema. Tunelis paprastai yra neteisingas atsakymas į šį konkretų klausimą.

Patikra 1: tas pats VPC ar skirtingi VPC

VPC yra regioninis ir apima pasiekiamumo zonas, o kiekvienas potinklis priklauso tiksliai vienai zonai. Du egzemplioriai skirtingose vieno VPC zonose vis dar yra tame pačiame privačiojo maršrutizavimo domene.

Skirtingi VPC niekada negauna privataus maršruto vien todėl, kad dalijasi regionu ar zonos žyme. Toks atvejis reikalauja palaikomo ryšio ir savo darbo su maršrutais bei leidimais, o tai yra atskiras sprendimas.

Patikra 2: ką sako potinklių maršrutizavimo lentelės

Užrašykite išdėstymą su tikromis reikšmėmis. VPC adresu 10.60.0.0/16 su potinkliais 10.60.1.0/24 ir 10.60.2.0/24 suteikia egzemplioriams 10.60.1.10 ir 10.60.2.20 kelią per VPC vietinį maršrutą.

Tada peržiūrėkite lenteles, susietas su abiem potinkliais, o ne tik tą, kurią radote pirmą. Konkretesnis patikros ar įrenginio maršrutas gali panaikinti bazinį maršrutą, o vietinio maršruto tikslas pats gali būti pakeistas naujesnėse konfigūracijose. Konsolėje kažkur matomas vietinis maršrutas neįrodo, kad abi darbo apkrovos jį naudoja.

Naudokite tuos privačius adresus ir pavadinimus, kuriuos VPC iš tikrųjų priskiria. Privatus adresas neprivalo prasidėti 10, o išgalvotas iš atminties adresas yra būdas neteisingai diagnozuoti veikiančią aplinką.

Patikra 3: maršrutizavimas ar autorizacija

Maršrutizavimas tik pristato paketą į tikslo tinklo sąsają. Tikslo saugos grupė vis tiek turi priimti šaltinį ir paslaugą, šaltinio išėjimo taisyklės turi leisti užklausą, o bet kuri tinklo ACL turi leisti abi kryptis, nes ACL neįsaugo būsenos.

Už to slypi svečio užkarda, klausytojo susiejimas ir pačios programos tapatybė. Kiekvienas iš jų gali atmesti užklausą, kurią maršrutizavimas pristatė nepriekaištingai.

Priėmimas turi būti tikroji programos operacija. Sėkmingas ping nesuteikia prieigos prie programos ir neįrodo, kad TLS pavadinimas ir prisijungimo duomenys yra teisingi, o užblokuotas ping neįrodo, kad visos privačios paslaugos neveikia.

Patikra 4: ar tikrai reikia atskiro ryšio

VPN vis tiek gali būti projekte, bet dėl nurodytos priežasties: prijungti šį VPC prie biuro, įleisti nešiojamuosius kompiuterius arba įvykdyti perdangos reikalavimą. Ši priežastis skiriasi nuo įprasto bendravimo tame pačiame VPC.

Prisiminkite ir tai, kas VPC nėra. Tai nėra namų Ethernet segmento tęsinys. Programai, kuri priklauso nuo transliavimo aptikimo, reikia atskiro vertinimo. Tai projekto spraga, o ne maršrutizavimo klaida.

Patikra 5: šifravimo klausimas

Privatus adresas ir leidimo taisyklė nieko nesako apie kriptografinę apsaugą programos sluoksnyje. Jei duomenims reikia apsaugos nuo galo iki galo, ji kyla iš protokolo ir tapatybės modelio, kuriuos paslauga iš tikrųjų palaiko.

Projektavimo pastaboje laikykite atskirai tinklo ir programos sluoksnių teiginius, nes jų sujungimas yra būdas, kuriuo peržiūra galiausiai teigia apsaugą, kurios niekas neįgyvendino.

Ką užrašyti

Užrašykite abu potinklių identifikatorius, su kiekvienu susietą maršrutizavimo lentelę, saugos grupių nuorodas ir programos operaciją, kurią išbandėte. Tai keturi faktai, ir jie išsprendžia daugumą būsimų ginčų dėl šio kelio.

Vien išdėstymas zonoje niekada nepasako, kad reikia pridėti VPN, ir niekada nepaaiškina, kodėl privati užklausa nepavyko.