Kva adresse ein skymur ser når VPN-en din er på
Ein full tunnel endrar kjeldeadressa databasen din ser. Flytt løyvelista, den private vegen eller den delte tunnelen, ikkje påloggingsinformasjonen.
Ein database som verkar før VPN-en koplar til og feilar etterpå, er sjeldan eit påloggingsproblem. Skymurar matchar kjeldeadresser, og ein full tunnel byter ut den dei matcha. Avstanden mellom det du trur den berbare sender, og det serveren tek imot, er heile feilen, og han kan målast i eitt steg.
Kva kjeldeadressa vert til
I ein full tunnel forlèt kvar pakke nettet gjennom VPN-gatewayen, så serveren ser den utgåande adressa til gatewayen i staden for heimekoplinga di. Om ein vidaresendande proxy ligg i vegen, er det adressa hans som kjem fram. Begge er legitime kjelder, og ingen av dei er adressa i den opphavlege regelen din.
Brannmurreglane i Azure SQL på server- og databasenivå matchar klientadressa som når den logiske serveren, som etter ein full tunnel er den utgåande adressa. Ei AWS-tryggingsgruppe som løyver éi adresse, oppfører seg på same måte. Pakken vert forkasta før autentisering, så feilen du får attende ser ut som ein nettverksfeil snarare enn eit løyveproblem. Det er nettopp difor folk byrjar å nullstilla passord.
Kvar løyvelista vert avgjord
Les regelen som svarar til den feilande vegen, ikkje regelen du hugsar at du oppretta. Noter omfanget, porten, protokollen og om han vert vurdert før noka identitetskontroll.
Deretter avgjer du kva lag som legitmt eig avgjerda. Ein adresseregel svarar på kvar trafikken kjem frå. Eit privat endepunkt svarar på om tenesta i det heile er tilgjengeleg via ein privat veg. Eit unntak for delt tunnel svarar på kva mål som går utanom tunnelen. Dei er ikkje utbyttbare, og kvar av dei feilar ulikt når tunnelen endrar seg.
Tre reparasjonar, tre lag
Kvart alternativ nedanfor rettar flyten av ein annan grunn, og vel du feil, får du ei kopling som verkar 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 |
Å leggja til den utgåande adressa er den minste endringa og den skjøraste, fordi ein ny gateway eller ein annan region gjer henne ugild i det stille. Dokumenter adressa ved sida av tunnelskildringa slik at dei to flyttar seg saman. Eit mellombels breitt område er ein diagnose, ikkje ein reparasjon; å la det stå er måten interne tenester endar med å vera eksponerte.
Kvifor ein administrert plattform ikkje kan vera med i tunnelen
Applikasjonsplattformer som Heroku, AppHarbor eller CloudBees køyrer koden din i eit miljø utan tun- eller tap-eining og utan rettar til å oppretta ei. Innkomande modell er HTTP og ikkje ein vilkårleg lyttande socket. Ein buildpack som leverer ei VPN-binærfil, har framleis ingen stad å setja grensesnittet. Dei brukbare mønstra er ei statisk utgåande adresse databasen kan løyva, eit privat tilkoplingsprodukt plattformen tilbyr, eller ein proxy i ein DMZ som ein når over HTTPS.
Den proxyen er ein tilgangsveg med eigen autentisering og logging. Han gjer ikkje plattformen til medlem av VPN-en din, og å skildra det slik gjev reglar ingen kan revidera.
Stadfest frå klienten som feila
Kopla til på nytt og gjer klienten si nøyaktige lei om att. Kontroller kjeldeadressa tenesta loggar, ruta klienten vel for databasenamnet, og resultatet av den faktiske spørjinga, i den rekkjefølgja. Ein test frå gatewayen provar at gatewayen verkar, noko som aldri var i tvil. Om koplinga no vert autentisert og spørjinga framleis feilar, er det gjenverande problemet databaseløyve.
Gå gjennom desse reglane kvar gong tunnelen endrar seg. Ein utskift gateway eller eit nytt utgåande område bryt vegen utan noka endring i applikasjonskonfigurasjonen i det heile.