GCP Cloud VPN: ellenőrizze az átjárót, az alagutat és a tűzfalat sorrendben

A konzol zöld alagutat mutat, a helyszíni monitorozás továbbra sem ér el egyetlen példányt sem, és az alagút újjáépítése kézenfekvő megoldásnak tűnik. Ritkán az. Egy létrejött alagút csak azt bizonyítja, hogy két átjáró befejezte az IKE-cserét. Semmit sem mond arról, hogy egy csomag valaha bejutott-e a VPC-jébe.

Négy döntés áll a zöld ikon és a válasz között, és kiszámítható sorrendben hibáznak. A legolcsóbbal kezdje.

Három objektum, és csak az egyikük titkosít

A VPN-átjáró birtokolja azt a külső címet, amelyre a partnere titkosít. A konzolban soha nem hozza létre kézzel: válasszon vagy foglaljon le egy címet a kapcsolat űrlapján belül, és az átjáró vele együtt jelenik meg. Az HA-átjáró két címet vesz fel két interfészen, ami később a kvótaellenőrzésnél számít.

Az alagút az átjáró és a partner közötti párosítás. Hordozza a megosztott titkot és a forgalmi szelektorokat, amelyek védelmét ígéri. Ezekben a szelektorokban kezdődik a legtöbb csendes hiba. Egy alagút, amelynek helyi szelektora 10.0.0.0/24-et fed le, nem szállít 10.0.1.0/24-et, bármilyen egészségesnek is látszik az állapot.

A túlsó vég saját listát tart, amelyet általában titkosítási tartománynak neveznek, és a lezáró hardver ezt a sajátjával hasonlítja össze. Egyik fél sem tárgyal olyan szelektorról, amelyet soha nem kapott meg.

Az útválasztási típus dönti el, mi kerül az útválasztási táblába

A Cloud VPN három útválasztási formát kínál, és ezek nem keverednek tisztán. A házirend-alapú útválasztás megtartja a statikus szelektorpárokat, az útvonal-alapú útválasztás elvárja, hogy Ön maga adjon hozzá statikus útvonalakat, a dinamikus útválasztás pedig előtagokat hirdet egy Cloud Routeren keresztül BGP-n. Válasszon egyet szándékosan.

Egy dinamikus alagút mellette kézzel írt statikus útvonalakkal olyan útválasztási táblát hoz létre, amely kiürül, valahányszor a BGP-munkamenet ingadozik.

A dinamikus az egyetlen forma, amely lehetővé teszi a védett előtagok megváltoztatását az alagút újjáépítése nélkül, és behúzza a Cloud Routert azon objektumok halmazába, amelyeket ellenőriznie kell. A statikus szelektorok akkor is működőképesek, ha a partner olyan hardveres tűzfal, amely nem tud BGP-t beszélni. Ilyenkor mindkét végnek ugyanazokra a tartományokra van szüksége, és a pontosabb bejegyzésnek mindkét oldalon nyernie kell. Egy pár, amely egy alhálózatban eltér, létrejön, majd a forgalma felét szállítja.

A hallgatólagos elutasítás az alagút mögött ül

A bejövő forgalmat a legalacsonyabb prioritású hallgatólagos elutasítással szemben értékelik, és ez a szabály nem törődik azzal, hogy a csomag titkosítva érkezett. Amíg egy tűzfalszabály nem nevezi meg a helyszíni tartományt és a használt portot, a csomag visszafejtésre, ellenőrzésre és eldobásra kerül. A VPN-napló végig tiszta marad, mert az alagút pontosan azt tette, amit ígért.

Olvassa inkább a tűzfal elutasítási naplóját, amikor az alagút él, és a próba időtúllépéssel végződik, majd szűkítse egy szabályt a forrástartományra és a szükséges portokra:

gcloud compute firewall-rules create allow-from-dc \
  --network=vpn-vpc \
  --direction=INGRESS \
  --source-ranges=192.168.10.0/24 \
  --allow=tcp:22,tcp:5432,icmp

Az egyirányú működés tűzfalra utal

A kimenő forgalom másképp viselkedik, mert a hallgatólagos engedélyező szabály bárhová küldheti a példányokat. Egy adatközpont, amely nem ér el egy VM-et, gyakran a másik irányban tökéletesen működő kimenő útvonal mögött ül. Ez az aszimmetria választja el a tűzfal kihagyását az útválasztási hibától, mivel az útválasztási hiba mindkét irányt egyszerre töri meg. Tesztelje az ellenkező irányt, mielőtt még egy szabályt szerkesztene.

A címek létrehozása is kvótaművelet. Egy projekt, amely közel van a használatban lévő külső címek korlátjához, olyan hibával utasítja el a kapcsolatot, amely engedélyezési hibának hangzik.

Szelektorok, kvóták, majd a négy ellenőrzés

A konzolban létrehozott alagutak néha üres távoli forgalmi szelektort adnak vissza a gcloud compute vpn-tunnels describe parancsból, miközben a generált útvonalak helyesen szállítják a forgalmat. Hasonlítsa össze, mit rögzít az API, azokkal a tartományokkal, amelyeket valóban véd, mielőtt eldöntené, hogy az alagút hibás. Az API-n vagy SDK-n keresztüli létrehozás kifejezetté teszi a szelektort.

A kvóták a másik könnyű kihagyás. A növelést a karbantartási ablak előtt kérje, ne közben, és ellenőrizze a címek számát ugyanabban a projektben, mint az átjáró.

Kívülről befelé dolgozzon: partner állapota, mindkét szelektorlista, útvonal mindkét oldalra, bejövő szabály a forrástartományra és a portra, majd csomagrögzítés. Írja be az átjáró címét, mindkét szelektorlistát és az útválasztási típust a változási jegybe, amíg az alagút új, mert a következő mérnöknek, aki alhálózatot ad hozzá, mindháromra szüksége lesz.