Kiun adreson vidas nuba fajroŝirmilo kiam via VPN estas ŝaltita
Plena tunelo ŝanĝas la fontadreson, kiun vidas via datumbazo. Movu la permesliston, la privatan vojon aŭ la dividitan tunelon, ne la akreditilon.
Datumbazo, kiu funkcias antaŭ ol la VPN konektiĝas kaj malsukcesas poste, malofte estas problemo pri akreditiloj. Nubaj fajroŝirmiloj kongruigas fontadresojn, kaj plena tunelo anstataŭigas tiun, kiun ili kongruigis. La diferenco inter tio, kion vi pensas, ke via tekkomputilo sendas, kaj tio, kion la servilo ricevas, estas la tuta cimo, kaj ĝi mezureblas per unu paŝo.
Kio fariĝas la fontadreso
En plena tunelo, ĉiu paketo eliras tra la VPN-enirejo, do la servilo vidas la eliran adreson de la enirejo anstataŭ vian hejman konekton. Se antaŭa prokura servilo staras sur la vojo, ĝia adreso estas tio, kio alvenas. Ambaŭ estas legitimaj fontoj, kaj nek unu estas la adreso en via origina regulo.
La fajroŝirmilaj reguloj de Azure SQL je servila kaj datumbaza niveloj kongruigas la klientan adreson, kiu atingas la logikan servilon, kiu post plena tunelo estas la elira adreso. AWS-sekureca grupo, kiu permesas unu adreson, kondutas same. La paketo estas forĵetata antaŭ aŭtentikigo, do la eraro, kiun vi ricevas, aspektas kiel reta fiasko anstataŭ permesa problemo. Ĝuste tial homoj komencas restarigi pasvortojn.
Kie la permeslisto estas decidata
Legu la regulon, kiu kongruas kun la fiaska vojo, ne la regulon, kiun vi memoras esti kreinta. Notu ĝian amplekson, ĝian pordon, ĝian protokolon kaj ĉu ĝi estas pritaksata antaŭ iu ajn identec-kontrolo.
Poste decidu, kiu tavolo laŭleĝe posedas la decidon. Adresa regulo respondas, de kie la trafiko venas. Privata finpunkto respondas, ĉu la servo tute atingeblas per privata vojo. Escepto pri dividita tunelo respondas, kiuj celoj preterpasas la tunelon. Ili ne estas interŝanĝeblaj, kaj ĉiu malsukcesas malsame kiam la tunelo ŝanĝiĝas.
Tri riparoj, tri tavoloj
Ĉiu opcio sube riparas la fluon pro malsama kialo, kaj elekti la malĝustan produktas konekton, kiu funkcias ĝis la sekva enireja ŝanĝo.
| 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 |
Aldoni la eliran adreson estas la plej malgranda ŝanĝo kaj la plej rompiĝema, ĉar nova enirejo aŭ alia regiono silente malvalidigas ĝin. Dokumentu la adreson apud la tunela difino, por ke ambaŭ moviĝu kune. Provizora larĝa intervalo estas diagnozo, ne riparo; lasi ĝin surloke estas kiel internaj servoj finiĝas malkaŝitaj.
Kial administrita platformo ne povas aliĝi al la tunelo
Aplikaj platformoj kiel Heroku, AppHarbor aŭ CloudBees ruligas vian kodon en medio sen aparato tun aŭ tap kaj sen privilegioj por krei unu. Ilia envena modelo estas HTTP, ne arbitra aŭskultanta ingo. Buildpack, kiu liveras VPN-dunumon, ankoraŭ ne havas lokon por la interfaco. La funkciantaj ŝablonoj estas statika elira adreso, kiun la datumbazo povas permesi, privata konekta produkto, kiun la platformo proponas, aŭ prokurilo en DMZ atingata per HTTPS.
Tiu prokurilo estas alirvojo kun propra aŭtentikigo kaj protokolado. Ĝi ne faras la platformon membro de via VPN, kaj tiel priskribi ĝin produktas regulojn, kiujn neniu povas revizii.
Kontrolu de la kliento, kiu malsukcesis
Rekonektu kaj ripetu la precizan klientan vojon. Kontrolu la fontadreson, kiun la servo registras, la itineron, kiun la kliento elektas por la datumbaza nomo, kaj la rezulton de la reala demando, en tiu ordo. Testo de la enirejo pruvas, ke la enirejo funkcias, kio neniam estis dubinda. Se la konekto nun aŭtentikiĝas kaj la demando ankoraŭ malsukcesas, la restanta problemo estas datumbaza permeso.
Revizuu ĉi tiujn regulojn ĉiufoje, kiam la tunelo ŝanĝiĝas. Anstataŭigita enirejo aŭ nova elira intervalo rompas la vojon sen iu ajn ŝanĝo en la aplikada agordo.