Watter adres ’n wolkfirewall sien sodra jou VPN aan is
’n Vol tonnel verander die bronadres wat jou databasis sien. Skuif die toelaatlys, die private pad of die gesplete tonnel, nie die geloofsbrief nie.
’n Databasis wat werk voordat die VPN koppel en daarna misluk, is selde ’n geloofsbriefprobleem. Wolkfirewalls pas bronadresse, en ’n vol tonnel vervang die een wat hulle pas. Die gaping tussen wat jy dink jou skootrekenaar stuur en wat die bediener ontvang, is die hele fout, en dit is in een stap meetbaar.
Wat die bronadres word
In ’n vol tonnel verlaat elke pakkie die netwerk deur die VPN-gateway, so die bediener sien die gateway se uitgangsadres eerder as jou tuisverbinding. As ’n proxy in die pad sit, is dit die proxy se adres wat aankom. Albei is geldige bronne, en nie een is die adres in jou oorspronklike reël nie.
Azure SQL se bediener- en databasisvlak-firewallreëls pas die kliëntadres wat die logiese bediener bereik, wat ná ’n vol tonnel die uitgangsadres is. ’n AWS-sekuriteitsgroep wat een adres toelaat, werk dieselfde. Die pakkie word voor verifikasie weggegooi, so die fout wat jy terugkry, lyk soos ’n netwerkfout eerder as ’n toestemmingsprobleem. Dit is juis hoekom mense begin om wagwoorde te herstel.
Waar die toelaatlys besluit word
Lees die reël wat by die mislukkende pad pas, nie die reël wat jy onthou jy geskep het nie. Let op sy omvang, sy poort, sy protokol en of dit voor enige identiteitskontrole geëvalueer word.
Besluit dan watter laag die besluit wettig besit. ’n Adresreël antwoord waar verkeer vandaan kom. ’n Privaat eindpunt antwoord of die diens hoegenaamd oor ’n private pad bereikbaar is. ’n Gesplete-tonnel-uitsondering antwoord watter bestemmings die tonnel omseil. Hulle is nie uitruilbaar nie, en elkeen misluk anders wanneer die tonnel verander.
Drie herstellings, drie lae
Elke opsie hieronder herstel die vloei om ’n ander rede, en die verkeerde een kies lewer ’n verbinding wat werk tot die volgende gateway-verandering.
| 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 |
Die uitgangsadres byvoeg is die kleinste verandering en die broosste, want ’n nuwe gateway of ’n ander streek maak dit stilweg ongeldig. Dokumenteer die adres langs die tonneldefinisie sodat die twee saam skuif. ’n Tydelike wye reeks is ’n diagnose, nie ’n herstelling nie; om dit te laat staan, is hoe interne dienste blootgestel word.
Hoekom ’n bestuurde platform nie by die tonnel kan aansluit nie
Toepassingsplatforms soos Heroku, AppHarbor of CloudBees laat jou kode loop in ’n omgewing sonder ’n tun- of tap-toestel en sonder regte om een te skep. Hul inkomende model is HTTP eerder as ’n willekeurige luisterende sok. ’n Boupakket wat ’n VPN-greep saamstuur, het steeds nêrens om die koppelvlak te plaas nie. Die werkbare patrone is ’n statiese uitgangsadres wat die databasis kan toelaat, ’n private verbindingsproduk wat die platform bied, of ’n proxy in ’n DMZ wat oor HTTPS bereik word.
Daardie proxy is ’n toegangspad met sy eie verifikasie en logboek. Dit maak nie die platform ’n lid van jou VPN nie, en om dit so te beskryf, lewer reëls op wat niemand kan oudit nie.
Verifieer vanaf die kliënt wat misluk het
Koppel weer en herhaal die presiese kliëntpad. Kontroleer die bronadres wat die diens log, die roete wat die kliënt vir die databasisnaam kies, en die uitslag van die werklike navraag, in daardie volgorde. ’n Toets vanaf die gateway bewys die gateway werk, wat nooit betwyfel is nie. As die verbinding nou verifieer en die navraag steeds misluk, is die oorblywende probleem databasis-toestemming.
Hersien hierdie reëls wanneer die tonnel verander. ’n Vervangde gateway of ’n nuwe uitgangsreeks breek die pad sonder enige verandering aan die toepassing se konfigurasie.