Místní databázový klient a privátní RDS: proč spojení vyprší

Notebooku vývojáře vyprší při připojení k privátnímu koncovému bodu RDS časový limit, zatímco stejné přihlašovací údaje fungují z bastion hostu. Nic nespadlo. Cestě mezi oním notebookem a databází chybí jedna ze tří věcí: jméno, které se přeloží, trasa, která nese provoz, nebo pravidlo bezpečnostní skupiny, které pustí zdroj, jenž databáze skutečně vidí. Zjistěte, která chybí, dřív než změníte zbývající dvě.

Čtěte selhání ve správné vrstvě

Časový limit není jedna chyba. Jméno, které se nepřeloží, selže dřív, než paket opustí stroj. Adresa bez trasy posílá pakety do černé díry. Filtrovaný port vytváří čekání, které vypadá přesně jako špatný hostitel. Proveďte kroky v pořadí a zastavte se u prvního, který selže.

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

Pokud jméno vrátí veřejnou adresu nebo nevrátí nic, tunel zatím není problém.

Pokud se jméno přeloží a test portu visí, porovnejte adresu, kterou jste přeložili, s adresou, kterou databáze hlásí. Spravovaný koncový bod se může přeložit na privátní adresu uvnitř VPC a na nic užitečného mimo ni, a adresa zkopírovaná ze starého vyhledávání bude ukazovat na hostitele, který už neodpovídá.

Oddělte tunel od trasy

Připojení klientské VPN automaticky nesměruje každý privátní rozsah. Profil nese trasy, které služba tlačí, a klient může nainstalovat jen některé z nich. Podívejte se, které rozsahy klient skutečně přidal a zda do některého spadá adresa databáze.

ip route get 10.20.40.15
ip addr show tun0

Trasa ukazující na rozhraní tunelu je nutná; není dostačující, protože protější strana musí provoz stále přijmout.

Profily rozděleného tunelu jsou obvyklým zdrojem tohoto polovičního selhání. Fungují pro aplikaci, pro kterou byl profil navržen, a nechávají rozsah databáze mimo tunel, což vytváří přesně ten časový limit, jaký by vytvořil firewall.

Slaďte bezpečnostní skupinu se skutečným zdrojem

Bezpečnostní skupina RDS pouští zdroje, ne lidi. Podle architektury může být zdrojem fond klientů VPN, privátní adresa bastionu nebo adresa NAT, na kterou se provoz překládá. Čtěte pravidlo a skutečný zdroj paketu společně.

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

Pravidlo pro domácí adresu jednoho notebooku je problém údržby, ne návrh přístupu.

Když je na cestě klientská VPN nebo NAT brána, databáze může vidět adresu překladatele místo adresy tunelu vývojáře. Proto pravidlo zkopírované z funkčního bastion nastavení může u notebooku selhat: obě cesty přicházejí z různých zdrojů, i když obě vypadají interně.

Dejte přednost úzké cestě před širokou

Když jeden vývojář potřebuje jednu databázi, je přesměrování založené na relaci často levnější na provoz než plný síťový tunel. Místní klient se připojí k přesměrovanému portu a vzdálená komponenta vytvoří spojení s databází zevnitř sítě.

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

Zachovejte v tomto návrhu ověřování TLS nedotčené. Klient má stále ověřit certifikát serveru proti jménu, které očekává; místní přesměrovaný port není důvod ověřování vypnout a jeho vypnutí skrývá právě ten problém identity, který stojí za to zachytit.

Volba mezi plným tunelem a úzkým přesměrováním je rozhodnutí o rozsahu, ne o bezpečnostním divadle.

Zanechte po sobě opakovatelnou cestu

Zdokumentujte jméno koncového bodu místo přeložené adresy, rozsah zdroje, který bezpečnostní skupina pouští, a roli databáze, kterou vývojář používá. Tyto tři skutečnosti vysvětlí většinu budoucích selhání bez telefonátu. Přidejte i verzi klientského profilu, protože změna profilu může odebrat trasu, kterou starý nesl.

Pak jednou otestujte negativní případ: klient mimo schválený zdroj má být stále odmítnut.

Privátní databáze, která funguje jen pro toho, kdo ji nastavil, není privátní přístup; je to nedokumentovaná výjimka čekající na znovuobjevení. Zapište cestu a další vývojář zdědí metodu místo záhady.