En databas som fungerar innan VPN ansluter och misslyckas efteråt är sällan ett inloggningsproblem. Molnbrandväggar matchar källadresser, och en full tunnel ersätter just den de matchade. Skillnaden mellan vad du tror att din bärbara dator skickar och vad servern tar emot är hela felet, och den går att mäta i ett steg.

Vad källadressen blir

I en full tunnel lämnar varje paket nätverket via VPN-gatewayen, så servern ser gatewayens utgående adress i stället för din hemanslutning. Om en vidarebefordrande proxy ligger i vägen är det dess adress som anländer. Båda är legitima källor, och ingen av dem är adressen i din ursprungliga regel.

Brandväggsreglerna i Azure SQL på server- och databasnivå matchar klientadressen som når den logiska servern, vilket efter en full tunnel är den utgående adressen. En AWS-säkerhetsgrupp som tillåter en enda adress beter sig likadant. Paketet släpps före autentiseringen, så felet du får tillbaka ser ut som ett nätverksfel snarare än ett behörighetsproblem. Det är precis därför folk börjar återställa lösenord.

Var tillåtelselistan avgörs

Läs regeln som matchar den felande vägen, inte regeln du minns att du skapade. Notera dess omfattning, port, protokoll och om den utvärderas före någon identitetskontroll.

Bestäm sedan vilket lager som legitimt äger beslutet. En adressregel svarar på var trafiken kommer ifrån. En privat slutpunkt svarar på om tjänsten över huvud taget är nåbar via en privat väg. Ett undantag för delad tunnel svarar på vilka destinationer som går förbi tunneln. De är inte utbytbara, och var och en misslyckas olika när tunneln ändras.

Tre reparationer, tre lager

Varje alternativ nedan reparerar flödet av en annan anledning, och det felaktiga valet ger en anslutning som fungerar till nästa gatewayändring.

RepairLayer it changesWhat it does not fix
Add the egress address to the ruleSource address matchingNothing about routing, and it breaks when the egress moves
Use a private endpointWhether the service is reached privatelyA client that still resolves the public name
Add a split-tunnel exceptionWhich flows bypass the tunnelAn expired credential or a wrong password

Att lägga till den utgående adressen är den minsta ändringen och den ömtåligaste, eftersom en ny gateway eller en annan region ogiltigförklarar den i tysthet. Dokumentera adressen bredvid tunneldefinitionen så att de två flyttar tillsammans. Ett tillfälligt brett intervall är en diagnos, inte en reparation; att låta det stå är hur interna tjänster till slut blir exponerade.

Varför en hanterad plattform inte kan ansluta till tunneln

Applikationsplattformar som Heroku, AppHarbor eller CloudBees kör din kod i en miljö utan tun- eller tap-enhet och utan rättigheter att skapa en. Deras inkommande modell är HTTP och inte en godtycklig lyssnande socket. Ett buildpack som levererar en VPN-binär har fortfarande ingen plats för gränssnittet. De fungerande mönstren är en statisk utgående adress som databasen kan tillåta, en privat anslutningsprodukt som plattformen erbjuder, eller en proxy i en DMZ som nås över HTTPS.

Den proxyn är en åtkomstväg med egen autentisering och loggning. Den gör inte plattformen till medlem i din VPN, och att beskriva det så ger regler som ingen kan granska.

Verifiera från klienten som misslyckades

Anslut igen och upprepa klientens exakta väg. Kontrollera källadressen som tjänsten loggar, rutten som klienten väljer för databasnamnet och resultatet av den faktiska frågan, i den ordningen. Ett test från gatewayen bevisar att gatewayen fungerar, vilket aldrig varit ifrågasatt. Om anslutningen nu autentiseras och frågan fortfarande misslyckas är det kvarvarande problemet databasbehörighet.

Granska dessa regler varje gång tunneln ändras. En utbytt gateway eller ett nytt utgående intervall bryter vägen utan någon ändring i applikationskonfigurationen alls.

Relaterade artiklar