API-t e Google përmes VPN: drejto VIP-in, jo vetëm nënrrjetin

Hyr në serverin lokal përmes SSH, ngri tunelin dhe VM-ja private përgjigjet; më pas thirrja e parë drejt një API të Google dështon pa rrugë. Nënrrjeti i VM-së dhe adresat VIP të API-t janë destinacione të ndryshme, prandaj një rrugë për njërën nuk zgjedh tjetrën. Tre kushte duhet të plotësohen përpara se një thirrje private e API-t të funksionojë. Emri i API-t duhet të zgjidhet në një VIP, prefiksi VIP duhet të shpallet përmes tunelit, dhe VPC-ja duhet të dijë si ta kthejë përgjigjen. Ping nuk të thotë asgjë për këtë, dhe as një sesion SSH që funksionon drejt një makine në nënrrjet.

Adresat VIP të API-t janë destinacione të veçanta

Google publikon VIP të dedikuara për aksesin në API nga rrjeta lokale, dhe pikërisht këto janë adresat që DNS-i yt duhet të kthejë për emrat e API-t. Të dyja janë prefikse të vegjël dhe asnjëra nuk është hapësirë RFC 1918:

Adresat që duken publike nuk do të thonë që rruga duhet të lërë tunelin për internetin e zakonshëm. Prefikset ekzistojnë që një klient lokal të arrijë front-end-et e Google përmes një rruge të mbështetur dhe jo përmes një pike daljeje arbitrare. Trajtoji si destinacione që i përkasin tunelit, jo si host-e për t’u hetuar. Një rregull firewalls i shkruar për dalje në internet zakonisht i hedh, dhe ky është një shkak i zakonshëm pse një thirrje dështon para se të fillojë.

DNS-i vendos se në cilin pikë fundore arrin

Drejto zgjidhësin lokal drejt regjistrimeve që Google dokumenton për pikën fundore të zgjedhur, që emrat që aplikacioni ka nevojë të përgjigjen me atë VIP. Vetëm googleapis.com nuk është inventar: regjistrat e paketave, regjistrat e kontejnerëve dhe lidhësit e migrimit kanë emrat e tyre të dokumentuar. Edhe VIP-i i kufizuar nuk mban çdo shërbim, prandaj një emër që zgjidhet mund të mbetet i pambështetur. Shkruaj domenet me të cilat aplikacioni kontakton vërtet përpara se të prekësh zgjidhësin.

Të hamendësosh një adresë VM në VPC në vend të një emri shërbimi nuk është rregullim, dhe zakonisht fsheh boshllëkun e DNS derisa të dështojë një klient tjetër.

Shpall prefiksin VIP, mbaj pjesën tjetër

Me një lidhje të bazuar në BGP, Cloud Router duhet të shpallë prefiksin VIP të zgjedhur që routeri lokal ta mësojë atë interval përmes sesionit të synuar. Shpallja vetëm e nënrrjeteve të VPC nuk e shton atë interval, dhe routeri lokal vazhdon të përdorë rrugën e tij të paracaktuar për ato adresa. Prefiksi në tabelën e rrugëzimit është prova e vetme që shpallja kaloi sesionin.

Mbaj shpalljet ekzistuese ndërsa shton të renë, sepse opsionet në nivel routeri dhe në nivel partneri kanë shtrirje të ndryshme, dhe ndryshimi i grupit mund të tërheqë rrjete që funksiononin tashmë. Më pas kontrollo shpalljen efektive në çdo sesion dhe jo në routerin në tërësi. Një prefiks që mungon dhe një prefiks i tërhequr duken njësoj nga ana lokale, prandaj pikërisht pamja e sesionit ndan lëshimin nga regresioni.

Ana e VPC-së ka nevojë për rrugën dhe rrugën e kthimit të vet

Brenda VPC-së, rruga e VIP-it duhet të përdorë portën e internetit të paracaktuar si hapin tjetër, dhe pavarësisht emrit ai trafik mbetet brenda rrjetit të Google. VPC-ja ka nevojë edhe për një rrugë kthimi drejt burimit lokal përmes VPN-së, dhe ky është një objekt i veçantë nga prefiksi i shpallur. Merr parasysh kërkesat rajonale të rrugëzimit të dokumentuara kur tuneli dhe klienti nuk janë në të njëjtin rajon.

Kontrollo rrugën e kthimit në mënyrë të pavarur, sepse një drejtim kërkese që funksionon mund të fshehë një drejtim përgjigjeje të prishur. Dy drejtime, dy rrugë, dhe secili dështon me simptomën e vet.

Testo kërkesën, pastaj lexo refuzimin

Ekoja ICMP nuk merr përgjigje nga këto VIP, prandaj një ping i dështuar nuk provon asgjë dhe një i suksesshëm shumë pak. Nga klienti real, shqyrto përgjigjen e emrit dhe rrugën e zgjedhur, pastaj bëj një kërkesë HTTPS të autorizuar drejt shërbimit që të intereson. Nëse kërkesa arrin shërbimin dhe refuzohet, shiko kredencialet, IAM dhe çdo politikë perimetri shërbimi që zbatohet.

Rrugëzimi privat nuk jep autorizim API dhe nuk ndryshon çfarë i lejohet identitetit. Suksesi i transportit dhe një përgjigje e autorizuar janë rezultate të ndara, dhe të duhen të dyja. Mbaj edhe rrugën IPv6 të qartë, sepse konfigurimi i prefikseve IPv4 nuk thotë asgjë për një klient që preferon IPv6.

Udhëzuesi i Google për Private Google Access nga rrjeta lokale mbulon bashkë regjistrimet DNS dhe kërkesat e rrugëzimit, prandaj krahaso cilësimet e tua të zgjidhësit dhe të shpalljes me të dhe jo me një postim forumi. Më pas ekzekuto sërish të njëjtën kërkesë dhe shëno përgjigjen dhe rrugën në të njëjtin tiketë.