Hvilken adresse en skybrannmur ser når VPN-en din er på
En full tunnel endrer kildeadressen databasen din ser. Flytt tillatelseslisten, den private veien eller den delte tunnelen, ikke påloggingsinformasjonen.
En database som virker før VPN-en kobler til og feiler etterpå, er sjelden et påloggingsproblem. Skybrannmurer matcher kildeadresser, og en full tunnel erstatter den de matchet. Avstanden mellom det du tror den bærbare sender, og det serveren mottar, er hele feilen, og den kan måles i ett steg.
Hva kildeadressen blir til
I en full tunnel forlater hver pakke nettverket gjennom VPN-gatewayen, så serveren ser gatewayens utgående adresse i stedet for hjemmeforbindelsen din. Hvis en videresendende proxy ligger i veien, er det dens adresse som ankommer. Begge er legitime kilder, og ingen av dem er adressen i den opprinnelige regelen din.
Brannmurreglene i Azure SQL på server- og databasenivå matcher klientadressen som når den logiske serveren, som etter en full tunnel er den utgående adressen. En AWS-sikkerhetsgruppe som tillater én adresse, oppfører seg på samme måte. Pakken forkastes før autentisering, så feilen du får tilbake ser ut som en nettverksfeil snarere enn et tillatelsesproblem. Det er nettopp derfor folk begynner å tilbakestille passord.
Hvor tillatelseslisten avgjøres
Les regelen som samsvarer med den feilende veien, ikke regelen du husker at du opprettet. Noter omfanget, porten, protokollen og om den vurderes før noen identitetskontroll.
Deretter avgjør du hvilket lag som legitimt eier beslutningen. En adresseregel svarer på hvor trafikken kommer fra. Et privat endepunkt svarer på om tjenesten i det hele tatt er tilgjengelig via en privat vei. Et unntak for delt tunnel svarer på hvilke mål som går utenom tunnelen. De er ikke utbyttbare, og hver av dem feiler ulikt når tunnelen endres.
Tre reparasjoner, tre lag
Hvert alternativ nedenfor retter flyten av en annen grunn, og velger du feil, får du en forbindelse som virker til neste gatewayendring.
| 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 |
Å legge til den utgående adressen er den minste endringen og den skjøreste, fordi en ny gateway eller en annen region ugyldiggjør den i det stille. Dokumenter adressen ved siden av tunneldefinisjonen slik at de to flytter seg sammen. Et midlertidig bredt område er en diagnose, ikke en reparasjon; å la det stå er måten interne tjenester ender med å være eksponert.
Hvorfor en administrert plattform ikke kan bli med i tunnelen
Applikasjonsplattformer som Heroku, AppHarbor eller CloudBees kjører koden din i et miljø uten tun- eller tap-enhet og uten rettigheter til å opprette en. Innkommende modell er HTTP og ikke en vilkårlig lyttende socket. En buildpack som leverer en VPN-binærfil, har fortsatt ingen plass å sette grensesnittet. De brukbare mønstrene er en statisk utgående adresse databasen kan tillate, et privat tilkoblingsprodukt plattformen tilbyr, eller en proxy i en DMZ som nås over HTTPS.
Den proxyen er en tilgangsvei med egen autentisering og logging. Den gjør ikke plattformen til medlem av VPN-en din, og å beskrive det slik gir regler ingen kan revidere.
Verifiser fra klienten som feilet
Koble til på nytt og gjenta klientens nøyaktige vei. Kontroller kildeadressen tjenesten logger, ruten klienten velger for databasenavnet, og resultatet av den faktiske spørringen, i den rekkefølgen. En test fra gatewayen beviser at gatewayen virker, noe som aldri var i tvil. Hvis forbindelsen nå autentiseres og spørringen fortsatt feiler, er det gjenværende problemet databasetillatelse.
Gå gjennom disse reglene hver gang tunnelen endres. En utskiftet gateway eller et nytt utgående område bryter veien uten noen endring i applikasjonskonfigurasjonen i det hele tatt.