Kateri naslov vidi oblačni požarni zid, ko je VPN vklopljen
Polni tunel spremeni izvorni naslov, ki ga vidi vaša baza podatkov. Premaknite seznam dovoljenih, zasebno pot ali razdeljeni tunel, ne poverilnic.
Baza podatkov, ki deluje pred povezavo VPN in po njej odpove, je le redko težava s poverilnicami. Oblačni požarni zidovi primerjajo izvorne naslove, polni tunel pa zamenja prav tistega, s katerim so jih primerjali. Razlika med tem, kar po vašem mnenju pošilja prenosnik, in tem, kar prejme strežnik, je celotna napaka, in izmeriti jo je mogoče v enem koraku.
Kaj postane izvorni naslov
V polnem tunelu vsak paket zapusti omrežje skozi prehod VPN, zato strežnik vidi izhodni naslov prehoda in ne vaše domače povezave. Če je na poti posredniški strežnik, prispe njegov naslov. Oba sta zakonita vira in noben ni naslov iz vašega prvotnega pravila.
Pravila požarnega zidu Azure SQL na ravni strežnika in baze podatkov primerjajo naslov odjemalca, ki doseže logični strežnik, in po polnem tunelu je to izhodni naslov. Varnostna skupina AWS, ki dovoli en naslov, se obnaša enako. Paket se zavrže pred preverjanjem pristnosti, zato je napaka, ki jo prejmete, videti kot omrežna okvara in ne kot težava z dovoljenji. Prav zato ljudje začnejo ponastavljati gesla.
Kje se odloči seznam dovoljenih
Preberite pravilo, ki ustreza poti, ki odpove, ne pravila, ki se spomnite, da ste ga ustvarili. Zabeležite njegov obseg, vrata, protokol in ali se ocenjuje pred kakršnim koli preverjanjem identitete.
Nato odločite, katera plast je zakonito lastnica te odločitve. Pravilo naslova odgovori, od kod prihaja promet. Zasebna končna točka odgovori, ali je storitev sploh dosegljiva po zasebni poti. Izjema za razdeljeni tunel odgovori, kateri cilji obidejo tunel. Niso zamenljive in vsaka odpove drugače, ko se tunel spremeni.
Tri popravila, tri plasti
Vsaka možnost spodaj popravi tok iz drugega razloga, izbira napačne pa da povezavo, ki deluje do naslednje spremembe prehoda.
| 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 |
Dodajanje izhodnega naslova je najmanjša sprememba in najbolj krhka, ker nov prehod ali druga regija to tiho razveljavita. Dokumentirajte naslov ob definiciji tunela, da se premikata skupaj. Začasen širok razpon je diagnostika, ne popravilo; pustiti ga na mestu je pot, po kateri notranje storitve na koncu ostanejo izpostavljene.
Zakaj se upravljana platforma ne more pridružiti tunelu
Aplikacijske platforme, kot so Heroku, AppHarbor ali CloudBees, izvajajo vašo kodo v okolju brez naprave tun ali tap in brez pravic, da bi jo ustvarile. Njihov vhodni model je HTTP in ne poljubna vtičnica, ki posluša. Buildpack, ki prinaša binarno datoteko VPN, še vedno nima kam postaviti vmesnika. Delujoči vzorci so statični izhodni naslov, ki ga baza podatkov lahko dovoli, produkt zasebne povezave, ki ga platforma ponuja, ali posredniški strežnik v DMZ, dosegljiv prek HTTPS.
Ta posredniški strežnik je pot dostopa z lastnim preverjanjem pristnosti in beleženjem. Platforme ne naredi za člana vašega VPN, in tako opisovanje ustvari pravila, ki jih nihče ne more revidirati.
Preverite pri odjemalcu, ki je odpovedal
Znova se povežite in ponovite natančno pot odjemalca. Preverite izvorni naslov, ki ga beleži storitev, pot, ki jo odjemalec izbere za ime baze podatkov, in rezultat dejanske poizvedbe, v tem vrstnem redu. Preizkus s prehoda dokazuje, da prehod deluje, kar nikoli ni bilo dvomljivo. Če se povezava zdaj preveri in poizvedba še vedno spodleti, je preostala težava dovoljenje v bazi podatkov.
Ta pravila pregledajte vsakič, ko se tunel spremeni. Zamenjan prehod ali novo izhodno območje prekineta pot brez kakršne koli spremembe v konfiguraciji aplikacije.