A VPN a VPC-be működik, de a felügyelt szolgáltatás időtúllépést kap
Az alagút az Ön peremén ér véget, nem a szolgáltató előajtajánál. Mielőtt útvonalat módosít, sorolja be a célpontot VM-en hosztolt, VPC-hez csatolt vagy csak nyilvános kategóriába.
Egy felügyelt adatbázis elérése VPN-en keresztül általában olyan okból vall kudarcot, amelyet senki nem írt le a runbookban: az alagút a hálózat peremén ér véget, miközben a szolgáltatás soha nem volt annak az Ön oldalán. Az útvonaltábla helyesnek látszik, az alagút működőnek jelenti magát, a kapcsolat mégis időtúllépést kap. Végezze el az alábbi négy ellenőrzést sorrendben, és álljon meg az elsőnél, amelynek sikerfeltétele nem teljesül, mert minden utána következő ellenőrzés feltételezi, hogy az előzőek teljesültek.
Első ellenőrzés: hol él valójában a végpont?
A VPN-átjáró két hálózatot köt össze, amelyek címzését Ön irányítja. A felügyelt szolgáltatás a szolgáltató saját előajtaja mögött fut, és ez az ajtó a terméktől függően három forma egyikét ölti. Ha nem tudja, melyik formával van dolga, semmilyen útvonalmunka nem segít, mert a hiba talán egyáltalán nem útvonalhiba.
| Shape | What it means | Pass condition |
|---|---|---|
| Software on your VM | Ordinary subnet addressing | Route and security group permit the client |
| Attached to your VPC | Private, but only inside that VPC | Endpoint associated, source allowed, route present |
| Provider-hosted, public endpoint | Optional private link, not private by default | A private endpoint exists and DNS points at it |
A legtöbb elpazarolt délután abból adódik, hogy ezt az osztályozást kihagyják, és egyenesen az útvonaltáblához mennek. A szolgáltatónál hosztolt, nyilvános végponttal rendelkező szolgáltatás nincs az alagútja mögött, bármit is mond a diagram, a VPC-hez csatolt pedig soha nem jelenik meg nyilvános DNS-válaszban.
Második ellenőrzés: VPC-hez csatolt szolgáltatás, például az ElastiCache
Az ilyen gyorsítótárak az Ön saját VPC-jén belül címzettek, és egyáltalán nincs internete felé néző figyelőjük. Az ugyanabban a VPC-ben végződő kliens VPN elérheti őket, de csak akkor, ha három feltétel együtt áll fenn. A gyorsítótár végpontjának olyan alhálózatokhoz kell kapcsolódnia, amelyeket az alagútja lát, a biztonsági csoportjának engedélyeznie kell a címet, ahonnan az ügyfelei érkeznek, és az ügyféloldalnak olyan útvonalra van szüksége, amely lefedi a gyorsítótár alhálózatait.
A gyakori hiba azt feltételezni, hogy egy közeli kapcsolat számít. A VPN másik VPC-hez kapcsolása, vagy kizárólag a peeringre támaszkodás nem terjeszti ki a gyorsítótár biztonsági csoportját vagy alhálózatának útvonaltábláját az ügyfeleire. Amikor a meglévő alagút máshol ér véget, a szokásos tartalék megoldás az adott VPC-n belül elhelyezett ugróhoszt vagy VPN-kiszolgáló. Ez a tartalék megoldás megkerülés és nem tervezés, és a runbookban így kell megjelölni.
Harmadik ellenőrzés: nyilvános nevű PaaS-végpont
Az Azure Database for PostgreSQL nyilvános kiszolgálónevet mutat. Nem ad olyan privát címet, amelyet be lehetne rögzíteni egy hosts fájlba, és átjárón keresztül átirányítani. A virtuális hálózati szolgáltatásvégpontok korlátozzák, mely alhálózatok érhetnek el egy erőforrást; nem jogosítanak fel egy helyszíni ügyfelet, amely VPN-en keresztül érkezik.
Privát hozzáférés megszerzése azt jelenti, hogy privát végpontot vagy privát kapcsolat kialakítást vezetünk be, majd privát DNS-zónát adunk hozzá, hogy a nyilvános név ezzel a végponttal válaszoljon az internet helyett. A VPN szolgáltatásvégpont-szabállyal kombinálva más architektúra, amely csak a diagramon látszik hasonlónak. Az App Service ugyanezt a logikát követi ellenkező irányból: a VNet-integráció lehetővé teszi az alkalmazásnak, hogy kimenő hívásokat tegyen egy VNetbe, és nem hoz létre bejövő privát útvonalat az alagútjából. A bejövő privát hozzáféréshez ezért privát végpont, App Service Environment vagy az alkalmazás elé helyezett átjáró szükséges, és hogy melyiket használhatja, a csomagtól függ.
Negyedik ellenőrzés: saját előajtóval rendelkező termékek
A Firebase Hosting nem csatolható Cloud VPN-hez, mert a hosztolási réteg globális frontvég, nem pedig valami egy projekt VPC-jén belül. A dokumentált alternatíva az, hogy saját maga építi fel az ellenőrzött belépési pontot, egy proxy-példánnyal vagy egy gyűjtőtárral megtámasztott terheléselosztóval. Akárhogy is, az oldal megszűnik tiszta hosztolási termék lenni, és olyan infrastruktúrává válik, amelyet most Ön üzemeltet. Ezt az alkut érdemes megnevezni, mielőtt valaki megígéri, hogy az alagút lefedi.
A Private API Gateway közelebb áll a VPC-szolgáltatások oldalához: egy interface típusú VPC-végpont olyan hosztnevet tesz közzé, amelynek válaszai privát címek, és az Ön telephelyéről érkező forgalom az alagúton vagy dedikált összeköttetésen keresztül érkezik. A végpontot az API-hoz kell kapcsolni, a tanúsítványnak és a hosztnévnek pedig meg kell egyeznie a hívók által használt egyéni tartománnyal.
A Google Cloud VPN alagutak társ-IP-címekhez kötődnek, nem nevekhez. A DNS-továbbítás külön konfigurálható, ezért az alagút teljesen egészséges lehet, miközben a távoli privát zónában végzett keresések továbbra is kudarcot vallanak.
Ezután határozza meg a határt
Futtassa ugyanazt a kapcsolatot a VPC-n belüli VM-ről. Amikor ott sikerül, a VPN-ügyféltől pedig nem, a rés az ügyfél útvonala és a szolgáltatás végpontja között van: egy útvonal, egy biztonsági csoport, egy végpontszabály vagy egy név. Amikor mindkét kísérlet kudarcot vall, abban a hálózatban semmi nem éri el a szolgáltatást, és a VPN soha nem volt az akadály.
getent hosts db.internal.example
nc -vz db.internal.example 5432A névfeloldást és a portellenőrzést külön végezze, mert különböző okokból vallanak kudarcot, és a pár megmondja, melyik fél útvonal sérült. Egy nyilvános címre feloldódó név azt mondja, hogy a privát DNS-zóna nincs játékban.