Einkaaðstaða Cloud SQL yfir VPN: leiðin sem enginn flytur út
Einkanetfang Cloud SQL virkar frá neti sem tengt er með VPN, en aðeins þegar bæði forskeyti biðlarans og þjónustusviðið standast tvö leiðamörk.
Mörg teymi trúa því að einkanetfang Cloud SQL virki aðeins innan VPC, og sú trú lifir af því bilunin lítur út eins og gagnagrunnsvandamál. Google skjalfestir aðgang frá netum sem eru tengd með Cloud VPN eða Cloud Interconnect. Það sem þessi net þurfa er ekki sérstakur gagnagrunnseiginleiki heldur tvö leiðaskipti sem auðvelt er að skilja eftir hálfstillt. Göngin koma upp, reikniplássin svara, og gagnagrunnstengingin rennur út á tíma — nákvæmlega sú samsetning sem sendir fólk á ranga stjórnborðið.
Goðsögn: einkanetfang þýðir einkaaðgangur að VPC
Aðgangur að einkatengdum þjónustum er VPC-peering milli netsins þíns og framleiðandanets í eigu Google. Úthlutað svið fyrir þjónustuna er á framleiðandahliðinni, og heimilisfang tilviksins er innan þess. Þessi peering er ástæðan fyrir því að gagnagrunnur í verkefninu þínu getur verið á heimilisfangi sem VPC-ið þitt leiðir til án þess að neitt skýrt undirnet þitt innihaldi það.
Þar sem þetta er peering hefur það einnig peering-hegðun, þar á meðal þann hlutann þar sem sérsniðnar leiðir fara ekki sjálfkrafa yfir.
Goðsögn: virk göng bera gagnagrunnsleiðina með sér
Tvö svið verða að standast ferðina. Það fyrra er forskeyti biðlarans: staðarnetið þitt verður að vera þekkt af Cloud Router með ákveðnum forskeytum, því sjálfgefna leið getur ekki veitt þann innflutning sem framleiðandanetið þarf fyrir afturleiðina. Það síðara er úthlutað þjónustusvið, sem ytri hliðin verður að læra svo pakkarnir hennar til gagnagrunnsins hafi eitthvert að fara. Þetta eru mismunandi leiðir sem viðhaldið er við mismunandi mörk, og að laga aðra skilur hina bilaða eftir.
Á Google-hliðinni þýðir það að kveikja á Export custom routes á viðkomandi peering-tengingum og bæta úthlutaða þjónustusviðinu við tilkynntar leiðir Cloud Router fyrir göngin.
Haltu tilkynningunum sem þegar eru til staðar. Að bæta þjónustusviðinu ætti ekki að fjarlægja VPC-leiðirnar sem sama BGP-lotan ber fyrir aðra umferð, og tilkynningasett sem er skipt út í heild er önnur bilun falin bak við þá fyrstu. Athugaðu einnig virkar leiðir á ytra tækinu, því að ná til VPN-gáttar eða annars undirnets sannar eingöngu flutning.
Goðsögn: Cloud SQL Auth Proxy leysir netið
The Auth Proxy veitir studda auðkenningu og dulkóðaðan flutning milli forritsins þíns og tilviksins. Það býr ekki til leið. Proxy sem ræst er á hýsli án slóðar að einkanetinu mun mistakast nákvæmlega eins og bein tenging myndi gera, og skrár þess verða minna gagnlegar um ástæðuna. Að færa proxyið á hýsil sem hefur tengingu breytir því hvaða hluti leiðarinnar þarf að virka, og það er raunveruleg hönnunarákvörðun en ekki krókaleið.
Það sem það gerir ekki er að leyfa ótengdri fartölvu að ná til tilviks sem er aðeins einkaaðgengilegt.
Goðsögn: Private Service Connect fylgir sömu reglum
Private Service Connect notar endapunkt í þínu eigin undirneti og DNS-fyrirkomulag sem þú stýrir, svo leiðin þangað er venjuleg leið að heimilisfangi sem þú átt. Útflutningsstillingar peering eiga ekki við um þá hönnun, og að afrita peering-breytingar inn í PSC-uppsetningu bætir við áhættu án þess að bæta við aðgengi.
Bæði gefa þér einkanetfang; líkindin enda þar.
Prófaðu leiðina í réttri röð
Frá ytri biðlaranum skaltu prófa TCP-endapunkt gagnagrunnsins fyrst. Lokið TCP-handaband þýðir að leiðsla, eldveggur og hlustandi eru allir til staðar, og næsta próf er leyfð auðkennd aðgerð. Hafnun auðkenningar er reyndar góð tíðindi á þeim tímapunkti, því hún sannar að hlustandi gagnagrunns svaraði. ICMP-tímarof segir næstum ekkert um gagnagrunnsaðgang, þar sem margar leiðir henda honum á meðan TCP er sent áfram án vandræða.
Ef biðlarasviðin þín eru utan RFC 1918 skaltu fara yfir viðbótarkröfur um útflutning leiða og netheimildir áður en þú ályktar að hönnunin sé óstudd.
Skráðu fjóra hluti með tengingunni: ytra forskeytið, úthlutaða þjónustusviðið, viðkomandi peering-tengingar og leiðarann sem tilkynnir. Þessir fjórir útskýra alla einkaleiðina, og þeir koma í stað þjóðsögunnar að Cloud SQL þurfi annaðhvort alltaf proxy eða sé alls ekki hægt að ná í gegnum VPN.