Recent Post
Google Cloud DNS- ja verkkoyhteysongelmat – mistä ne johtuvat ja miten ne ratkaistaan?
Google Cloud -ympäristössä verkkoyhteyden pitäisi käyttäjän näkökulmasta olla yksinkertainen asia. Sovellus kutsuu palvelua, nimi ratkaistaan IP-osoitteeksi ja liikenne kulkee perille.
Käytännössä näin ei aina käy.
Yksi palvelu ei yhtäkkiä saa yhteyttä tietokantaan. Sovellus toimii kehitysympäristössä, mutta tuotannossa sama osoite ei ratkea. Sisäinen palvelunimi toimii yhdestä VPC-verkosta, mutta toisesta verkosta ei. Tai yhteys näyttää olevan kunnossa, mutta pyyntö päättyy timeoutiin ilman selkeää virheilmoitusta.
Tällaisissa tilanteissa ongelmaa on helppo lähteä etsimään väärästä paikasta. Sovelluskoodia muutetaan, palomuurisääntöjä avataan liian laajasti tai DNS-asetuksia kokeillaan summittaisesti. Joskus näillä muutoksilla ongelma häviääkin, mutta samalla ei välttämättä selviä, mikä sen alun perin aiheutti.
Google Cloudin verkkoympäristössä DNS ja verkkoyhteydet muodostavat ketjun, jossa usean eri palvelun pitää toimia yhtä aikaa. VPC-verkko, subnetit, reitit, palomuurisäännöt, DNS-asetukset, Private Google Access, Cloud NAT, VPN tai Cloud Interconnect ja käytettävä Google Cloud -palvelu voivat kaikki vaikuttaa lopputulokseen.
Siksi vian selvittäminen kannattaa aloittaa kysymällä hyvin yksinkertainen kysymys:
Mihin asti yhteys oikeasti toimii?
Jos nimeä ei saada ratkaistua, ongelma on eri kuin silloin, kun DNS toimii mutta TCP-yhteyttä ei synny. Ja jos TCP-yhteys syntyy mutta TLS tai sovellustason pyyntö epäonnistuu, verkkoa ei välttämättä tarvitse muuttaa lainkaan.
DNS-ongelma ei aina ole DNS-palvelimen vika
➠ DNS:n tehtävä on lopulta melko yksinkertainen: nimi muutetaan osoitteeksi.
➠ Cloud-ympäristössä kokonaisuus on kuitenkin hieman monimutkaisempi. Sovellus voi käyttää julkista verkkotunnusta, yksityistä DNS-nimeä, palvelun sisäistä nimeä tai esimerkiksi yrityksen omassa verkossa ylläpidettyä nimipalvelua.
➠ Google Cloudissa käytetään Cloud DNS:ää moniin erilaisiin tarkoituksiin. Samassa ympäristössä voi lisäksi olla muita DNS-palvelimia, esimerkiksi yrityksen omassa konesalissa.
➠ Tästä syntyy yksi käytännön ongelma: sovellus ei välttämättä käytä sitä DNS-palvelua, jota ylläpitäjä kuvittelee sen käyttävän.
➠ Kun esimerkiksi virtuaalikone ei löydä nimeä, ensimmäinen tarkistus kannattaa tehdä suoraan kyseisestä ympäristöstä. Jos Linux-koneessa suoritetaan esimerkiksi:
dig api.example.internal
tai
nslookup api.example.internal
dig api.example.internal
tai
nslookup api.example.internal
➠ saadaan nopeasti selville, palauttaako DNS lainkaan vastausta.
➠ Jos vastausta ei tule, on vielä liian aika päätellä, että Cloud DNS on rikki. Ensin pitää selvittää, mitä nimipalvelinta kysely käyttää ja kuuluuko kyseinen nimi juuri sen hallinnoitavaksi.
Private DNS ja julkinen DNS ovat eri asioita
Yksi tavallinen väärinkäsitys syntyy siitä, että sama nimi ajatellaan automaattisesti ratkaistavaksi samalla tavalla kaikkialla.
Yrityksessä voi olla esimerkiksi sisäinen nimi:
database.company.internal
database.company.internal
Sitä ei ole tarkoitettu julkiseen Internetiin. Sen ratkaiseminen voi perustua Cloud DNS:n private zoneen tai yrityksen omaan DNS-infrastruktuuriin.
Jos VPC-verkko, jossa sovellus toimii, ei pääse käyttämään kyseistä zonea tai DNS-polku on väärin määritetty, sovellus ei löydä palvelua.
Tässä vaiheessa DNS-ongelman korjaaminen ei tarkoita uuden julkisen DNS-tietueen lisäämistä. Päinvastoin, julkisen nimen lisääminen voi olla väärä ratkaisu ja jopa turvallisuusriski.
Parempi tapa on selvittää ensin:
- missä DNS-zone sijaitsee
- onko zone public vai private
- mihin VPC-verkkoihin private zone on liitetty
- mistä DNS-kysely tulee
- mitä IP-osoitetta vastauksessa pitäisi tulla
- muuttuuko vastaus eri verkoista katsottuna
Erityisesti hybridiverkoissa tämä tarkistus on tärkeä.
Kun Google Cloud ja yrityksen oma verkko eivät puhu samaa DNS-kieltä
Monissa yrityksissä Google Cloud ei ole ainoa verkkoympäristö. Sovellus voi olla pilvessä, mutta tietokanta, ERP, identiteettipalvelu tai jokin muu järjestelmä sijaitsee edelleen yrityksen omassa konesalissa.
Silloin DNS:n täytyy toimia molempiin suuntiin.
Esimerkiksi Google Cloudissa oleva sovellus voi yrittää kutsua:
erp.company.local
erp.company.local
Nimi saattaa olla olemassa ainoastaan yrityksen omassa DNS-palvelussa.
Pelkkä VPN-yhteys ei kuitenkaan ratkaise tätä. VPN voi toimia täydellisesti ja DNS-kyselyt voivat silti mennä väärään paikkaan.
Tällaisessa tilanteessa kannattaa erottaa kaksi asiaa toisistaan:
1. Löytyykö kohteen IP-osoite?
2. Pääseekö sovellus kyseiseen IP-osoitteeseen?
1. Löytyykö kohteen IP-osoite?
2. Pääseekö sovellus kyseiseen IP-osoitteeseen?
Jos ensimmäinen epäonnistuu, tutkitaan DNS:ää.
Jos nimi ratkaistaan oikein mutta toinen vaihe epäonnistuu, katse siirtyy reititykseen, palomuuriin, VPN:ään tai kohdejärjestelmään.
Tämä jako säästää yllättävän paljon aikaa.
VPC-yhteys voi olla kunnossa vain osittain
➠ Google Cloudin VPC-verkko ei ole vain yksi iso verkko, jossa kaikki resurssit näkevät toisensa.
➠ Subnetworkit, reitit ja palomuurisäännöt määrittävät, miten liikenne kulkee.
➠ Esimerkiksi kaksi Compute Engine -instanssia voivat sijaita saman VPC:n sisällä, mutta liikenne niiden välillä voi silti epäonnistua palomuurisäännön vuoksi.
➠ Toisessa tilanteessa sovellus voi päästä ulkoiseen API-palveluun, mutta ei yrityksen sisäiseen IP-osoitteeseen. Tämä voi johtua täysin erilaisesta reitityksestä.
➠ Siksi kannattaa ensin piirtää hyvin yksinkertainen kuva liikenteestä:
Sovellus
|
v
VPC
|
+—- DNS
|
+—- Route
|
+—- Firewall
|
+—- VPN / Interconnect / NAT
|
v
Kohdepalvelu
➠ Jos jokin näistä kohdista ei ole selvä, ongelman ratkaiseminen muuttuu helposti arvailuksi.
Reitti löytyy, mutta liikenne ei kulje
Google Cloudin reitityksessä yksi tärkeä asia on erottaa toisistaan reitin olemassaolo ja liikenteen salliminen.
Reitti voi olla täysin kunnossa, mutta firewall estää liikenteen.
Toisaalta firewall voi sallia liikenteen, mutta reittiä kohteeseen ei ole.
Esimerkiksi sovellus yrittää muodostaa yhteyden:
10.20.30.15:443
10.20.30.15:443
Jos DNS on jo ratkaistu ja IP-osoite näyttää oikealta, seuraava kysymys on, pääseekö liikenne kyseiseen verkkoon.
Tässä kohtaa ping ei aina ole hyödyllinen testi. ICMP voidaan estää, vaikka TCP-portti 443 toimisi normaalisti.
Parempi testi voi olla esimerkiksi:
nc -vz 10.20.30.15 443
nc -vz 10.20.30.15 443
Jos TCP-yhteys ei muodostu, ongelmaa voidaan tutkia verkon tasolla.
Jos yhteys muodostuu mutta HTTPS-pyyntö epäonnistuu, ongelma voi olla TLS:ssä, sertifikaatissa, palvelimessa tai itse sovelluksessa.
Firewall-säännöissä kannattaa katsoa liikenteen suunta
Palomuurisäännöissä ongelma ei aina ole itse IP-osoitteessa. Myös liikenteen suunta ja kohteen tunnistus vaikuttavat.
Käytännössä kannattaa tarkistaa ainakin:
- mistä liikenne tulee
- mihin se on menossa
- mikä protokolla on käytössä
- mikä portti tarvitaan
- mitä lähdettä firewall-sääntö käyttää
- osuvatko kyseiset resurssit sääntöön
- onko liikenne todella sitä tyyppiä, jota sääntö sallii
Liian laaja sääntö voi tietenkin ratkaista yhteysongelman, mutta sitä ei pitäisi pitää hyvänä lopullisena ratkaisuna.
Tuotantoympäristössä parempi lopputulos on yleensä mahdollisimman tarkka sääntö, joka sallii tarvittavan liikenteen ilman ylimääräisiä oikeuksia.
Cloud NAT ratkaisee yhden ongelman – ei kaikkia
➠ Cloud NAT tulee vastaan erityisesti ympäristöissä, joissa Compute Engine -instansseilla ei ole julkisia IP-osoitteita mutta niiden pitää päästä Internetiin.
➠ Jos sovellus yrittää esimerkiksi kutsua ulkoista HTTPS-rajapintaa, liikenteelle täytyy olla toimiva ulospääsy.
➠ Ilman sopivaa NAT-ratkaisua yhteys voi yksinkertaisesti päättyä timeoutiin.
➠ Tässäkin kannattaa kuitenkin varmistaa kokonaisuus. Pelkkä Cloud NAT -konfiguraation olemassaolo ei vielä tarkoita, että liikenne toimii.
➠ Tarkistettavia asioita ovat esimerkiksi:
- onko subnet mukana NAT-konfiguraatiossa
- onko reititys kunnossa
- onko kohde Internetissä
- estääkö firewall ulospäin lähtevän liikenteen
- käyttääkö sovellus oikeaa DNS-nimeä
- palauttaako kohde vastauksen
➠ Jos ulkoinen API toimii selaimesta mutta ei Google Cloudissa olevasta palvelusta, ongelma ei välttämättä ole API:ssa. Ero voi olla yksinkertaisesti siinä, miten pilviympäristön ulospäin lähtevä liikenne on rakennettu.
Private Google Access aiheuttaa joskus hämmennystä
Google Cloudissa on palveluita, joita halutaan käyttää ilman, että liikenne kulkee tavalliseen tapaan julkisen Internetin kautta.
Tällöin Private Google Access voi olla olennainen osa ratkaisua.
Jos VM:llä ei ole ulkoista IP-osoitetta, mutta sen pitäisi käyttää Googlen palveluita, verkkopolku pitää suunnitella tätä varten.
Tässä yhteydessä DNS:n, reitityksen ja subnetin asetukset liittyvät toisiinsa. Jos yksi osa puuttuu, virheilmoitus voi näyttää sovelluksen näkökulmasta melko epämääräiseltä.
Siksi tuotantohäiriössä kannattaa välttää ajatusta:
“Google Cloudin API ei vastaa.”
“Google Cloudin API ei vastaa.”
Parempi kysymys on:
“Pääseekö tämä resurssi kyseiseen Google-palveluun juuri tästä verkosta?”
“Pääseekö tämä resurssi kyseiseen Google-palveluun juuri tästä verkosta?”
Se on paljon hyödyllisempi lähtökohta vianhakuun.
VPN voi toimia, vaikka sovellus ei silti pääse palveluun
➠ Hybridiyhteyksissä yksi hankalimmista tilanteista on se, että VPN näyttää olevan kunnossa.
➠ Tunnelissa ei näy selvää virhettä. Reitit näyttävät oikeilta. Silti sovellus ei saa yhteyttä yrityksen sisäiseen palveluun.
➠ Tällöin kannattaa katsoa liikennettä päästä päähän.
➠ Esimerkiksi:
Google Cloud VM
|
v
VPC route
|
v
Cloud VPN
|
v
Yrityksen palomuuri
|
v
Sisäinen verkko
|
v
Palvelin
➠ Jos yhteys pysähtyy yrityksen palomuurille, Google Cloudin asetusten muuttaminen ei auta.
➠ Myös paluureitti on tärkeä. Pyyntö voi lähteä pilvestä oikein, mutta vastaus ei löydä takaisin.
➠ Tämä on yksi niistä verkkovioista, joita on vaikea huomata, jos tarkastellaan vain Google Cloudin puolta.
DNS toimii, mutta väärä IP-osoite tulee vastaukseksi
Kaikki DNS-ongelmat eivät tarkoita sitä, ettei nimeä löydy.
Joskus nimi löytyy aivan oikein, mutta palautettu osoite on väärä.
Tämä voi tapahtua esimerkiksi silloin, kun DNS-tietue on muuttunut, private zone peittää julkisen vastauksen tai eri ympäristöissä käytetään eri osoitteita.
Esimerkiksi:
api.company.fi
api.company.fi
voi tuotannossa osoittaa yhteen osoitteeseen ja testiympäristössä toiseen.
Kun ongelmaa tutkitaan, kannattaa siis katsoa myös itse DNS-vastaus:
dig api.company.fi
dig api.company.fi
Tarvittaessa voidaan tarkastella tarkemmin myös nimipalvelimen toimintaa:
dig +trace api.company.fi
dig +trace api.company.fi
Kaikki dig-komennon käyttöön liittyvät ongelmat eivät tietenkään vaadi tracea. Usein tavallinen DNS-kysely riittää kertomaan, onko vastaus odotettu.
Kun sovellus saa yhteyden mutta pyyntö silti epäonnistuu
Verkkoyhteyden onnistuminen ei vielä tarkoita, että sovellus toimii.
Kuvitellaan, että palvelu kutsuu HTTPS-rajapintaa.
DNS toimii.
TCP-yhteys muodostuu.
TLS-yhteys alkaa.
Silti API palauttaa virheen.
Tässä vaiheessa verkkoinfrastruktuurin muuttaminen ei välttämättä ole enää oikea toimenpide.
Ongelma voi olla esimerkiksi:
- TLS-sertifikaatissa
- SNI-tiedoissa
- HTTP Host -otsakkeessa
- autentikoinnissa
- palvelun sallimassa lähdeosoitteessa
- sovelluksen käyttämässä endpointissa
- kohdepalvelun omassa palomuurissa
Tämä on hyvä esimerkki siitä, miksi verkkovikaa ei kannata määritellä pelkän virheilmoituksen perusteella.
Connection timeout ja HTTP 401 ovat kaksi täysin erilaista ongelmaa.
Google Cloudin palvelujen välinen liikenne
➠ Cloud Run, GKE, Compute Engine, Cloud SQL ja muut Google Cloud -palvelut eivät muodosta automaattisesti yhtä yksinkertaista verkkopolkuja kaikissa käyttötapauksissa.
➠ Esimerkiksi Cloud Run -palvelun ja Cloud SQL -instanssin välinen yhteys vaatii oikean yhteysratkaisun. GKE:n tapauksessa mukaan tulevat myös klusterin verkotus, podien ja nodien osoitteet sekä mahdolliset Network Policy -asetukset.
➠ Kun palvelu ei saa yhteyttä toiseen Google Cloud -palveluun, ensimmäinen tehtävä on tunnistaa:
- Sen jälkeen voidaan selvittää, millaista verkkoreittiä kyseinen yhteys käyttää.
- Tämä kuulostaa itsestään selvältä, mutta tuotantohäiriössä juuri tämä tieto voi puuttua. Dokumentaatiossa lukee “palvelu käyttää Cloud SQL:ää”, mutta kukaan ei ole kirjannut, miten yhteys käytännössä muodostetaan.
Mistä resurssista yhteys lähtee ja mihin se menee?
GKE:ssä ongelma voi olla podin ja noden välillä
Kubernetes lisää verkkoympäristöön oman kerroksensa.
Jos GKE:ssä oleva pod ei pääse palveluun, pelkän VM:n testaaminen ei aina riitä. Node voi päästä kohteeseen samalla kun podin liikenne käyttäytyy eri tavalla.
Siksi vianhaku kannattaa tehdä mahdollisimman läheltä ongelmaa.
Jos mahdollista, tarkista esimerkiksi:
nslookup palvelu.internal
ja
curl -v https://palvelu.internal
nslookup palvelu.internal
ja
curl -v https://palvelu.internal
suoraan kyseisestä workloadista tai mahdollisimman vastaavasta ympäristöstä.
Näin voidaan erottaa DNS-ongelma, verkkoyhteysongelma ja HTTP-tason ongelma toisistaan.
Cloud DNS -ongelmaa kannattaa tutkia kysely kerrallaan
DNS:n kanssa yksi hyödyllinen tapa on seurata kyselyä pienissä osissa.
Ensimmäiseksi:
dig palvelu.example.internal
dig palvelu.example.internal
Jos vastaus on odotettu, tarkista IP-osoite.
Sen jälkeen:
nc -vz 10.10.20.15 443
nc -vz 10.10.20.15 443
Jos TCP-yhteys toimii, voidaan siirtyä HTTPS-tasolle:
curl -v https://palvelu.example.internal
curl -v https://palvelu.example.internal
Tämän kolmen vaiheen avulla voidaan jo rajata valtava määrä mahdollisia vikoja.
DNS
↓
TCP
↓
TLS / HTTP
Jos DNS epäonnistuu, ei ole järkeä aloittaa tutkimusta TLS-sertifikaatista.
Jos TCP-yhteys ei synny, HTTP-koodin tutkiminen ei yleensä auta.
Jos HTTP palauttaa 500, verkkoyhteys on todennäköisesti jo riittävän pitkällä ja ongelmaa pitää etsiä sovelluksesta.
Logging ja Network Intelligence eivät korvaa perustason testausta
➠ Google Cloud tarjoaa verkkoliikenteen tutkimiseen useita työkaluja. VPC Flow Logs, Firewall Rules Logging ja Network Intelligence Center voivat antaa erittäin hyödyllistä tietoa.
➠ Niiden arvo näkyy erityisesti silloin, kun ongelma ei ole suoraan nähtävissä sovelluksen lokissa.
➠ Esimerkiksi firewall-lokit voivat auttaa selvittämään, osuuko liikenne tiettyyn sääntöön. Flow Logs taas voivat kertoa liikenteen kulusta, vaikka sovellus itse ei antaisi juuri mitään hyödyllistä tietoa.
➠ Työkaluja ei kuitenkaan kannata käyttää irrallaan perusasioista.
➠ Jos dig kertoo, että DNS palauttaa väärän osoitteen, ensin korjataan DNS.
➠ Jos oikea osoite löytyy mutta TCP-yhteys ei synny, tutkitaan verkkoa.
➠ Jos TCP toimii ja HTTPS epäonnistuu, siirrytään seuraavalle tasolle.
➠ Näin vianhaku pysyy hallittavana.
Tuotannossa tärkeintä on tietää, mikä muuttui
Moni verkkohäiriö alkaa lauseella:
“Tämä toimi vielä eilen.”
“Tämä toimi vielä eilen.”
Se on itse asiassa hyödyllinen tieto.
Jos sovelluskoodia ei muutettu, mutta yhteys lakkasi toimimasta, kannattaa tarkistaa myös infrastruktuurissa tapahtuneet muutokset.
Esimerkiksi:
- DNS-tietue muuttui
- VPC:n reititystä muutettiin
- firewall-sääntöä päivitettiin
- uusi subnet otettiin käyttöön
- VPN-konfiguraatio vaihtui
- sertifikaatti uusittiin
- palvelu siirrettiin toiseen ympäristöön
- Terraform-muutos otettiin käyttöön
- GKE-klusteria päivitettiin
- Cloud Runin verkkoasetuksia muutettiin
Tässä kohtaa versionhallinta ja Infrastructure as Code ovat erittäin hyödyllisiä.
Jos infrastruktuuri on hallittu Terraformilla, muutoksesta pitäisi olla mahdollista nähdä, mitä oikeasti muuttui. Ilman tätä tietoa vianhaku muuttuu helposti käsin tehtäväksi vertailuksi.
Älä korjaa verkkovikaa avaamalla kaikkea
Tuotannossa yksi houkutteleva ratkaisu on tehdä palomuurista hetkeksi mahdollisimman salliva.
Se saattaa todistaa, että firewall oli mukana ongelmassa. Mutta jos sääntö jätetään pysyvästi liian avoimeksi, vian korjaamisesta tulee samalla tietoturvaongelma.
Parempi tapa on käyttää testiä rajauksen tekemiseen.
Jos liikenne toimii, kun sääntö sallii tietyn lähteen ja portin, voidaan seuraavaksi tarkistaa, mikä tarkka sääntö tarvitaan.
Lopullisen konfiguraation pitäisi vastata todellista liikennettä, ei vianhakuhetken kiirettä.
Sama pätee DNS:ään. Jos sisäinen palvelu ei löydy, julkisen DNS-tietueen lisääminen ei ole automaattisesti oikea ratkaisu.
Mitä hyvä Google Cloud -verkkovianhaku käytännössä tarkoittaa?
➠ Hyvä vianhaku ei ole sitä, että tunnet kaikki Google Cloudin verkkoasetukset ulkoa.
➠ Paljon tärkeämpää on osata rajata ongelma.
➠ Kun yhteys ei toimi, eteneminen voi olla esimerkiksi tällainen:
Mihin yhteys on menossa?
Onko kohde VPC:n sisällä, toisessa VPC:ssä, yrityksen konesalissa vai Internetissä?
Mikä palvelu yrittää muodostaa yhteyden?
Onko kyseessä VM, GKE-podi, Cloud Run vai jokin muu workload?
Ratkeaako nimi?
Tarkista DNS suoraan siitä ympäristöstä, jossa ongelma tapahtuu.
Onko IP-osoite oikea?
Väärä DNS-vastaus voi näyttää verkkovialta.
Muodostuuko TCP-yhteys?
Jos ei, tutki reitit, firewall ja mahdollinen NAT/VPN-yhteys.
Päästäänkö TLS- ja HTTP-tasolle?
Jos kyllä, ongelma ei välttämättä enää ole verkossa.
Mikä muuttui ennen ongelmaa?
Tämä kysymys voi olla koko selvityksen tärkein.
➠ Tässä järjestyksessä tutkittaessa ongelma alkaa yleensä muuttua epämääräisestä “verkko ei toimi” -tilanteesta konkreettiseksi viaksi.
Lopuksi
Google Cloudin DNS- ja verkkoyhteysongelmat voivat näyttää sovellustiimin silmissä hyvin samanlaisilta: pyyntö aikakatkeutuu, palvelu ei löydy tai API ei vastaa.
Syy voi kuitenkin olla aivan eri paikassa.
Jos DNS ei ratkaise nimeä, kyse on yhdestä ongelmasta. Jos nimi ratkaistaan mutta reitti puuttuu, kyse on toisesta. Jos reitti toimii mutta firewall estää liikenteen, ratkaisu löytyy jälleen eri kohdasta. Ja jos HTTPS-yhteys syntyy mutta palvelu palauttaa virheen, verkon muuttaminen ei välttämättä auta lainkaan.
Tuotantoympäristössä tärkeintä ei ole tehdä mahdollisimman monta muutosta mahdollisimman nopeasti. Tärkeämpää on saada selville, missä kohtaa yhteysketju katkeaa.
Kun DNS, reititys, firewall, NAT, VPN ja sovellustaso käsitellään erillisinä vaiheina, myös vaikea verkkohäiriö muuttuu huomattavasti helpommaksi selvittää.