VPN VPC:hen toimii, mutta hallinnoitu palvelu aikakatkeaa
Tunneli päättyy reunallesi, ei palveluntarjoajan etuoveen. Luokittele kohde VM:ssä isännöidyksi, VPC:hen liitetyksi tai vain julkiseksi ennen kuin muutat reittiä.
Hallinnoidun tietokannan saavuttaminen VPN:n kautta epäonnistuu yleensä syystä, jota kukaan ei kirjoittanut ohjeeseen: tunneli päättyy verkkosi reunaan, kun taas palvelu ei ole koskaan ollut sen sinun puolellasi. Reittitaulukko näyttää oikealta, tunneli ilmoittaa olevansa käynnissä ja yhteys aikakatkeaa silti. Käy alla olevat neljä tarkistusta järjestyksessä läpi ja pysähdy ensimmäiseen, jonka läpäisyehto ei täyty, koska jokainen seuraava tarkistus olettaa edellisten täyttyneen.
Tarkistus yksi: missä päätepiste oikeasti sijaitsee?
VPN-yhdyskäytävä yhdistää kaksi verkkoa, joiden osoitteistoa hallitset. Hallinnoitua palvelua käytetään palveluntarjoajan oman etuoven takana, ja tuo ovi saa tuotteesta riippuen yhden kolmesta muodosta. Jos et tiedä, minkä muodon kanssa olet tekemisissä, mikään reittityö ei auta, koska vika ei välttämättä ole reittivika lainkaan.
| 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 |
Suurin osa hukatuista iltapäivistä syntyy siitä, että tämä luokittelu ohitetaan ja mennään suoraan reittitaulukkoon. Palveluntarjoajan isännöimä palvelu, jolla on julkinen päätepiste, ei ole tunnelisi takana mitä tahansa kaavio sanoo, eikä VPC:hen liitetty palvelu koskaan ilmesty julkiseen DNS-vastaukseen.
Tarkistus kaksi: VPC:hen liitetty palvelu, kuten ElastiCache
Sellaiset välimuistit osoitetaan oman VPC:si sisällä, eikä niillä ole lainkaan internetiin suunnattua kuuntelijaa. Samassa VPC:ssä päättyvä asiakas-VPN voi tavoittaa ne, mutta vain kun kolme ehtoa osuu yhteen. Välimuistin päätepisteen on oltava liitetty aliverkkoihin, jotka tunnelisi näkee, sen tietoturvaryhmän on sallittava osoite, josta asiakkaasi tulevat, ja asiakaspuolella tarvitaan reitti, joka kattaa välimuistin aliverkot.
Yleinen virhe on olettaa, että jossain lähellä oleva yhteys lasketaan. VPN:n liittäminen toiseen VPC:hen tai pelkkään peeringiin nojaaminen ei laajenna välimuistin tietoturvaryhmää tai sen aliverkon reittitaulukkoa asiakkailleisi. Kun nykyinen tunneli päättyy muualla, tavallinen vararatkaisu on samassa VPC:ssä oleva hyppykone tai VPN-palvelin. Tällainen vararatkaisu on kiertotie eikä suunnitteluratkaisu, ja se pitäisi merkitä sellaiseksi ohjeessa.
Tarkistus kolme: PaaS-päätepiste julkisella nimellä
Azure Database for PostgreSQL esittää julkisen palvelinnimen. Se ei anna sinulle yksityistä osoitetta, jonka voisit kiinnittää hosts-tiedostoon ja reitittää yhdyskäytävän kautta. Virtuaaliverkon palvelupäätepisteet rajoittavat, mitkä aliverkot voivat tavoittaa resurssin; ne eivät valtuuta paikallista asiakasta, joka saapuu VPN:n kautta.
Yksityisen pääsyn saaminen tarkoittaa yksityisen päätepisteen tai private link -ratkaisun käyttöönottoa ja sitten yksityisen DNS-vyöhykkeen lisäämistä, jotta julkinen nimi vastaa kyseisellä päätepisteellä internetin sijaan. VPN yhdessä palvelupäätepistesäännön kanssa on toinen arkkitehtuuri, joka näyttää samalta vain kaaviossa. App Service seuraa samaa logiikkaa vastakkaisesta suunnasta: VNet-integraatio sallii sovelluksen tehdä lähteviä kutsuja VNetiin, eikä se luo tunnelistasi saapuvaa yksityistä polkua. Saapuva yksityinen pääsy vaatii siis yksityisen päätepisteen, App Service -ympäristön tai sovelluksen eteen sijoitetun yhdyskäytävän, ja se, mitä niistä voit käyttää, riippuu palvelutasosta.
Tarkistus neljä: tuotteet, joilla on oma etuovensa
Firebase Hostingia ei voi liittää Cloud VPN:ään, koska isännöintikerros on maailmanlaajuinen etupää eikä jotain projektin VPC:n sisällä. Dokumentoitu vaihtoehto on rakentaa valvottu sisäänkäynti itse, proxy-instanssilla tai säiliöllä tuetulla kuormantasaimella. Kummassakin tapauksessa sivusto lakkaa olemasta puhdas isännöintituote ja muuttuu infrastruktuuriksi, jota sinä nyt ylläpidät. Tämä vaihtokauppa kannattaa nimetä ennen kuin joku lupaa tunnelin kattavan sen.
Private API Gateway on lähempänä VPC-palveluiden puolta: interface-tyyppinen VPC-päätepiste julkaisee isäntänimen, jonka vastaukset ovat yksityisiä osoitteita, ja liikenne tiloistasi saapuu tunnelin tai dedikoidun yhteyden kautta. Päätepiste on liitettävä API:in, ja varmenteen sekä isäntänimen on vastattava mukautettua verkkotunnusta, jota kutsujat käyttävät.
Google Cloud VPN -tunnelit sitoutuvat vertais-IP-osoitteisiin, eivät nimiin. DNS-edelleenlähetys määritetään erikseen, ja siksi tunneli voi olla täysin terve, kun taas haut etäisellä yksityisellä vyöhykkeellä epäonnistuvat edelleen.
Paikanna sitten raja
Aja sama yhteys VPC:n sisäiseltä VM:ltä. Kun se onnistuu siellä ja epäonnistuu VPN-asiakkaalta, aukko on asiakkaan polun ja palvelun päätepisteen välissä: reitti, tietoturvaryhmä, päätepistekäytäntö tai nimi. Kun molemmat yritykset epäonnistuvat, mikään siinä verkossa ei tavoita palvelua, eikä VPN ollut koskaan este.
getent hosts db.internal.example
nc -vz db.internal.example 5432Tee nimihaku ja porttitarkistus erikseen, koska ne epäonnistuvat eri syistä ja pari kertoo, kumpi puoli polusta on rikki. Nimi, joka ratkeaa julkiseksi osoitteeksi, kertoo sinulle, että yksityinen DNS-vyöhyke ei ole pelissä.