Jakou adresu vidí cloudový firewall, když je VPN zapnutá
Plný tunel mění zdrojovou adresu, kterou vaše databáze vidí. Přesuňte seznam povolených adres, soukromou cestu nebo rozdělený tunel, ne přihlašovací údaje.
Databáze, která funguje před připojením VPN a potom selže, jen zřídka bývá problém s přihlašovacími údaji. Cloudové firewally porovnávají zdrojové adresy a plný tunel nahrazuje tu, se kterou porovnávaly. Rozdíl mezi tím, co si myslíte, že váš notebook odesílá, a tím, co server přijímá, je celá chyba a lze ho změřit jediným krokem.
Čím se zdrojová adresa stane
V plném tunelu opouští každý paket síť přes bránu VPN, takže server vidí výstupní adresu brány, nikoli vaše domácí připojení. Pokud je na cestě dopředný proxy server, dorazí jeho adresa. Obě jsou legitimní zdroje a ani jedna není adresa z vašeho původního pravidla.
Pravidla firewallu Azure SQL na úrovni serveru a databáze porovnávají adresu klienta, která dorazí k logickému serveru, což je po plném tunelu výstupní adresa. Bezpečnostní skupina AWS povolující jednu adresu se chová stejně. Paket se zahodí před autentizací, takže chyba, kterou dostanete, vypadá jako selhání sítě, ne jako problém s oprávněními. Právě proto lidé začínají resetovat hesla.
Kde se rozhoduje seznam povolených adres
Přečtěte si pravidlo, které odpovídá selhávající cestě, ne pravidlo, které si pamatujete, že jste vytvořili. Všimněte si jeho rozsahu, portu, protokolu a toho, zda se vyhodnocuje před jakoukoli kontrolou identity.
Potom rozhodněte, která vrstva toto rozhodnutí legitimně vlastní. Pravidlo adresy odpovídá na to, odkud provoz přichází. Soukromý koncový bod odpovídá na to, zda je služba vůbec dostupná přes soukromou cestu. Výjimka pro rozdělený tunel odpovídá na to, které cíle tunel obcházejí. Nejsou zaměnitelné a každá selhává jinak, když se tunel změní.
Tři opravy, tři vrstvy
Každá možnost níže opravuje tok z jiného důvodu a volba té nesprávné dává připojení, které funguje do další změny brány.
| Repair | Layer it changes | What it does not fix |
|---|---|---|
| Add the egress address to the rule | Source address matching | Nothing about routing, and it breaks when the egress moves |
| Use a private endpoint | Whether the service is reached privately | A client that still resolves the public name |
| Add a split-tunnel exception | Which flows bypass the tunnel | An expired credential or a wrong password |
Přidání výstupní adresy je nejmenší změna a nejkřehčí, protože nová brána nebo jiný region ji tiše zneplatní. Zdokumentujte adresu vedle definice tunelu, aby se obě pohybovaly společně. Dočasný široký rozsah je diagnostika, ne oprava; ponechat ho na místě je způsob, jak nakonec vnitřní služby zůstanou vystavené.
Proč se spravovaná platforma nemůže připojit k tunelu
Aplikační platformy jako Heroku, AppHarbor nebo CloudBees spouštějí váš kód v prostředí bez zařízení tun nebo tap a bez oprávnění ho vytvořit. Jejich vstupní model je HTTP, ne libovolný naslouchající socket. Buildpack, který dodává binárku VPN, stále nemá kam umístit rozhraní. Fungující vzory jsou statická výstupní adresa, kterou může databáze povolit, produkt soukromého připojení, který platforma nabízí, nebo proxy v DMZ dostupný přes HTTPS.
Tento proxy je přístupová cesta s vlastní autentizací a protokolováním. Nečiní z platformy člena vaší VPN a takový popis vytváří pravidla, která nikdo nemůže auditovat.
Ověřte to z klienta, který selhal
Připojte se znovu a zopakujte přesnou cestu klienta. Zkontrolujte zdrojovou adresu, kterou služba zaznamenává, trasu, kterou klient volí pro název databáze, a výsledek skutečného dotazu, v tomto pořadí. Test z brány dokazuje, že brána funguje, což nikdy nebylo sporné. Pokud se připojení nyní autentizuje a dotaz stále selhává, zbývajícím problémem je oprávnění v databázi.
Tato pravidla kontrolujte pokaždé, když se tunel změní. Vyměněná brána nebo nový rozsah výstupních adres přeruší cestu bez jakékoli změny konfigurace aplikace.