Lokálny databázový klient a privátny RDS: prečo spojenie vyprší

Notebooku vývojára vyprší pri pripájaní k privátnemu koncovému bodu RDS časový limit, hoci rovnaké prihlasovacie údaje fungujú z bastion hostu. Nič nespadlo. Ceste medzi tým notebookom a databázou chýba jedna z troch vecí: meno, ktoré sa preloží, trasa, ktorá nesie prevádzku, alebo pravidlo bezpečnostnej skupiny, ktoré pustí zdroj, ktorý databáza skutočne vidí. Zistite, ktorá chýba, skôr než zmeníte zvyšné dve.

Čítajte zlyhanie v správnej vrstve

Časový limit nie je jedna chyba. Meno, ktoré sa nepreloží, zlyhá skôr, než paket opustí stroj. Adresa bez trasy posiela pakety do čiernej diery. Filtrovaný port vytvára čakanie, ktoré vyzerá presne ako nesprávny hostiteľ. Vykonajte kroky v poradí a zastavte sa pri prvom, ktorý zlyhá.

dig +short db.internal.example
nc -vz db.internal.example 5432

Ak meno vráti verejnú adresu alebo nič, tunel zatiaľ nie je problém.

Ak sa meno preloží a test portu visí, porovnajte adresu, ktorú ste preložili, s adresou, ktorú databáza hlási. Spravovaný koncový bod sa môže preložiť na privátnu adresu vo vnútri VPC a na nič užitočné mimo nej, a adresa skopírovaná zo starého vyhľadávania bude ukazovať na hostiteľa, ktorý už neodpovedá.

Oddeľte tunel od trasy

Pripojenie klientskej VPN automaticky nesmeruje každý privátny rozsah. Profil nesie trasy, ktoré služba tlačí, a klient môže nainštalovať len niektoré z nich. Pozrite sa, ktoré rozsahy klient skutočne pridal a či do niektorého nespadá adresa databázy.

ip route get 10.20.40.15
ip addr show tun0

Trasa ukazujúca na rozhranie tunela je nutná; nie je postačujúca, pretože protistrana musí prevádzku stále prijať.

Profily rozdeleného tunela sú obvyklým zdrojom tohto polovičného zlyhania. Fungujú pre aplikáciu, pre ktorú bol profil navrhnutý, a nechávajú rozsah databázy mimo tunela, čo vytvára presne ten časový limit, aký by vytvoril firewall.

Zosúlaďte bezpečnostnú skupinu so skutočným zdrojom

Bezpečnostná skupina RDS púšťa zdroje, nie ľudí. Podľa architektúry môže byť zdrojom fond klientov VPN, privátna adresa bastionu alebo adresa NAT, na ktorú sa prevádzka prekladá. Čítajte pravidlo a skutočný zdroj paketu spolu.

aws ec2 describe-security-groups --group-ids sg-0123456789abcdef0 \
  --query 'SecurityGroups[].IpPermissions'

Pravidlo pre domácu adresu jedného notebooku je problém údržby, nie návrh prístupu.

Keď je na ceste klientska VPN alebo brána NAT, databáza môže vidieť adresu prekladača namiesto adresy tunela vývojára. Preto pravidlo skopírované z fungujúceho bastion nastavenia môže pri notebooku zlyhať: obe cesty prichádzajú z rôznych zdrojov, hoci obe vyzerajú interne.

Uprednostnite úzku cestu pred širokou

Keď jeden vývojár potrebuje jednu databázu, presmerovanie založené na relácii je často lacnejšie na prevádzku než plný sieťový tunel. Lokálny klient sa pripojí k presmerovanému portu a vzdialená komponenta vytvorí spojenie s databázou zvnútra siete.

ssh -N -L 5432:db.internal.example:5432 bastion.internal.example

V tomto návrhu zachovajte overovanie TLS nedotknuté. Klient má stále overiť certifikát servera voči menu, ktoré očakáva; lokálny presmerovaný port nie je dôvod overovanie vypnúť a jeho vypnutie skrýva presne ten problém identity, ktorý stojí za to zachytiť.

Voľba medzi plným tunelom a úzkym presmerovaním je rozhodnutie o rozsahu, nie o bezpečnostnom divadle.

Zanechajte po sebe opakovateľnú cestu

Zdokumentujte meno koncového bodu namiesto preloženej adresy, rozsah zdroja, ktorý bezpečnostná skupina púšťa, a rolu databázy, ktorú vývojár používa. Tieto tri fakty vysvetlia väčšinu budúcich zlyhaní bez telefonátu. Pridajte aj verziu klientskeho profilu, pretože zmena profilu môže odobrať trasu, ktorú starý niesol.

Potom raz otestujte negatívny prípad: klient mimo schváleného zdroja má byť stále odmietnutý.

Privátna databáza, ktorá funguje len pre toho, kto ju nastavil, nie je privátny prístup; je to nedokumentovaná výnimka čakajúca na znovuobjavenie. Zapíšte cestu a ďalší vývojár zdedí metódu namiesto záhady.