Cloud Run helyszíni VPN-hez: közvetlen VPC-egress beállítása

A Cloud VPN-alagút nem teszi rá a Cloud Run-t a hálózatra. Csatlakoztassa a szolgáltatást a megfelelő alhálózathoz, irányítsa a forrástartományát, majd tesztelje azt a revíziót.

Az alagút él, egy VM eléri a helyszíni kiszolgálót, a Cloud Run szolgáltatás mégis időtúllépést kap ugyanazon a gazdagépen. Ez a feladat szokásos kiindulópontja, és az alagút ritkán a hibás. A Cloud Run revízió alapértelmezés szerint nem ül a VPC-jében, és amikor igen, a saját forrás- címeit használja, nem pedig azt a VM-alhálózatot, amelyet már átirányított. Az alábbi runbook csatlakoztatja a szolgáltatást, átirányítja a tényleges forrástartományát, majd bizonyítja az utat abból a revízióból, amely kiszolgálta a kérést. Ebben a sorrendben futtassa, mert az első lépés kihagyása az oka, hogy ezek közül a esetek közül oly sok egy semmit nem javító VPN-módosítással végződik.

A revízió csatlakoztatása az alagút hibakeresése előtt

A Cloud Run támogatja a közvetlen VPC-egress szolgáltatást, amely a szolgáltatás forgalmát a VPC-je egy alhálózatára helyezi Serverless VPC Access-összekötő nélkül. Egy meglévő szolgáltatás esetén a frissítés így néz ki:

gcloud run services update SERVICE \
  --region=REGION --network=NETWORK --subnet=SUBNET \
  --vpc-egress=private-ranges-only

Cserélje ki a helyőrzőket, vizsgálja át, mit tesz az üzembe helyezés az élő forgalommal, és válasszon a szolgáltatás régiójában egy alhálózatot megfelelő cí kapacitással és a helyes hálózati engedélyekkel.

Válassza a célhoz illő egress-módot

private-ranges-only a privátként osztályozott célpontokat a VPC-n keresztül küldi. Ez nem azt jelenti, hogy „minden, ami a VPN-en át elérhető”, és ez a rés akkor jelenik meg, amikor a helyszíni szolgáltatás olyan tartományban van, amelyet a beállítás nem így osztályoz. Ha a célpont nincs lefedve, akkor a all-traffic a másik dokumentált mód, és mindent a VPC-n keresztül küld, beleértve a szolgáltatás nyilvános függőségeit is. Válasszon tudatosan, és írja le a következményt a változásjegyzékbe.

Az összekötőt már használó szolgáltatás migrációt igényel, nem kapcsolót, ezért tervezze meg, ahelyett hogy mindkettőt beállítaná.

A Cloud Run forrását irányítsa, ne egy VM forrását

A közvetlen VPC-egress ideiglenes címeket oszt ki a kiválasztott alhálózatból, és a helyszíni oldalnak vissza kell irányítania a forgalmat erre a tartományra. Egy másik VM-alhálózathoz írt visszairányítási útvonal vagy tűzfalengedély a diagramon helyesnek tűnik, a gyakorlatban meghibásodik. Az alhálózat CIDR-jét a VPC-ből vegye, ne emlékezetből, majd erősítse meg, hogy a távoli eszköz kripto ACL-je vagy útválasztási táblája tartalmazza.

Dinamikus útválasztás esetén ellenőrizze, mit hirdet valójában a Cloud Router, és mit importál a VPC, beleértve minden egyéni hirdetési szabályzatot. Az a útvonal, amely a konzolban létezik, de nincs kiválasztva erre a célra, ugyanaz, mintha nem lenne útvonal.

Három feltétel, amelynek mind teljesülnie kell

Egy működő útvonalhoz mindegyikre szükség van, és mindegyik a maga módján hibázik:

  • Egy útvonal a VPC-ben a helyszíni előtag felé a szándékolt Cloud VPN-kapcsolaton keresztül.
  • Egy visszirányú útvonal a helyszíni oldalon a Cloud Run alhálózatához.
  • Tűzfal- és IPsec-védelmi hatókör, amely engedi a forrást, a célt és a portot.

A hiányzó útvonal általában időtúllépésnek tűnik, a távoli oldalon semmilyen bizonyíték nélkül. A visszirányú útvonal problémája úgy néz ki, mint egy megérkező kérés és egy eltűnő válasz. A tűzfal vagy a szelektor problémája eszköztől függően elutasításnak vagy csendes eldobásnak tűnhet. Annak megállapítása, hogy melyik a három közül, jelentősen szűkíti a következő parancsot.

Ne tegyen egyetlen ideiglenes Cloud Run-címet az engedélyezési listára. Használja az alhálózat tartományát és az alkalmazáshoz illő engedélyezési tervet.

Tesztelje azt a revíziót, amely kiszolgálta a kérést

A tesztelés előtt vizsgálja meg az üzembe helyezett hálózati beállításokat és a forgalom felosztását, mert egy frissítés új revíziót hozhat létre, miközben a kérések még egy régebbihez érkeznek. Ezután hajtsa végre ugyanazt a műveletet, amelyet a felhasználói kérés végrehajt, abból a revízióból. Ha a cél egy privát gazdagépnév, ellenőrizze annak feloldását abban a környezetben és a létrejött címet, mert a laptopja vállalati DNS-válasza semmit nem bizonyít a szolgáltatás névteréről. Tartsa meg a TLS-gazdagépnév ellenőrzését és a távoli alkalmazás saját hitelesítését.

Számítson a dokumentált Direct VPC-indítási kapcsolódási késedelmekre, és adjon az ügyfélnek készenléti vagy újrapróbálkozási stratégiát ahelyett, hogy minden hideg indítást törött alagútként diagnosztizálna.

Visszaállítás és amit ez nem tesz

A visszaállításhoz állítsa vissza a szolgáltatás hálózati és egress-beállításait a korábbi értékeikre, és erősítse meg, hogy a korábbi revízió továbbra is kiszolgálja a forgalmat. Tartsa meg a gcloud-parancsot a változásjegyzékben, mert egy részleges változás fordítottja hat hét múlva nem nyilvánvaló. A VPC-csatlakozás eltávolítása visszaállítja a szolgáltatást a korábbi egress-útvonalára, ami egy incidens során éppen az lehet, amit szeretne.

Ez a kialakítás lefedi a Cloud Run által kezdeményezett kapcsolatokat és azok válaszait. Nem ad a helyszíni hálózatnak címezhető socketet a szolgáltatáson belül, mert a befelé irányuló kitettség ingress-döntés.

Kapcsolódó cikkek