IP-továbbítás engedélyezése egy meglévő GCE VPN-átjárón

A VM IP-továbbítás nélkül jött létre, már futtatja a VPN-szoftvert, és az ösztön az, hogy a sablonból újraépítsük a bekapcsolt jelzővel. Ez az újjáépítés felesleges. A Compute Engine frissíthető tulajdonságként teszi elérhetővé a canIpForwardot, és a dokumentált frissítési útvonal restart helyett refresh mellett alkalmazza. Amit a jelző valójában vezérel, az szűk: nélküle a platform eldobja azokat a csomagokat, amelyek megérkeznek a példányhoz, de nem a példány saját címére vannak címezve. Az az átjáró, amely más gépek forgalmát továbbítja, pontosan ezt teszi, ezért a jelzőnek be kell lennie. Minden, ami ezután következik, vendégkonfiguráció és útválasztás, amelyekhez a jelző nem nyúl.

Mit enged a jelző, és mit nem

Kikapcsolt továbbítás mellett a platform végpontként kezeli a példányt. Azok a csomagok kézbesítődnek, amelyek célja a példány saját címe; azok, amelyeket a példánynak más nevében kellene továbbadnia, nem.

Bekapcsolt továbbítás mellett a példány VPC-útvonal következő ugrásaként működhet, és ez az a szerep, amelyre egy VPN-eszköznek szüksége van. A jelző semmit nem mond a tűzfalakról, a vendég útválasztásáról, az alagút konfigurációjáról vagy a visszaútvonalakról, és a true érték egy hibás átjárón továbbra is hibás átjáró.

Olvassa ki a jelenlegi tulajdonságot

Vizsgálja meg a beállítást, mielőtt bármit módosítana, egy csak olvasható describe használatával a szándékolt példány, projekt és zóna ellen:

gcloud compute instances describe VM_NAME --project PROJECT_ID --zone ZONE --format='value(canIpForward)'

A false érték csak akkor számít, ha ezt a VM-et következő ugrásnak szánják. Ha igen, az útvonal többi részét továbbra is külön kell ellenőrizni, mert a tulajdonság egyetlen sor egy hosszabb láncban.

Frissítse a meglévő példányt

A Google példánytulajdonság-frissítési eljárása exportálja az aktuális erőforrást, módosítja a tulajdonságot és benyújtja az eredményt. Ez más munkafolyamat, mint a létrehozáskori --can-ip-forward jelző, és ez az, amely futó VM-en működik.

Először exportálja a definíciót egy helyi fájlba, és tartson meg egy változatlan másolatot az összehasonlításhoz:

gcloud compute instances export VM_NAME --project PROJECT_ID --zone ZONE --destination=instance.yaml

Ebben az exportált fájlban állítsa be a tulajdonságot, és ne módosítson semmi mást:

canIpForward: true

Tartsa meg a teljes erőforrást, az ujjlenyomatával együtt. A fájl egysoros YAML-dokumentummal való helyettesítése, vagy a géptípushoz, lemezhez vagy interfészhez tartozó, egymással nem összefüggő módosítások ugyanabba a beküldésbe csomagolása az az út, amelyen egy tulajdonságváltozásból kiesés lesz.

Kérje meg a frissítési mechanizmust, hogy ellenőrizze a fájlt, és jelentse, mire lenne szükség, mielőtt bármilyen tényleges változás engedélyezhető:

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=NO_EFFECT

Ez az ellenőrző futás nem kapcsolja be a továbbítást. Olvassa el a választ az érvénytelen tulajdonságokról és arról a műveletről, amelyet szükségesnek mond. Ennél az elkülönített változásnál a dokumentált művelet a REFRESH. Ha az eredmény újraindítást kér, a fájl többet tartalmaz, mint a módosítani kívánt tulajdonság, ezért vizsgálja meg, ahelyett hogy megadná az újraindítást.

Alkalmazza az átnézett fájlt a refresh-korláttal:

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=REFRESH

Ellenőrizze, hogy a művelet befejeződött, és futtassa újra a describe parancsot. Ha az ujjlenyomat már nem egyezik, valaki más módosította a példányt a szerkesztés közben, ezért exportáljon friss másolatot, és nézze át újra a változást, ahelyett hogy átkényszerítené az elavult fájlját.

A vendégnek továbbra is továbbítania kell a csomagot

A felhőengedély nem tesz egy eszközt routerré. Erősítse meg, hogy egy VPC-útvonal ezt a VM-et választja következő ugrásként a cél-előtaghoz, és hogy a vendég saját továbbítási házirendjének bekapcsolásával továbbít az alagút és a megfelelő interfész között.

A tűzfal-szabályzatnak engednie kell a belső folyamot és a külső figyelőt is. Csak a VPN-port megnyitása a titkosított átvitelt írja le, és semmit nem mond a benne zajló alkalmazáscseréről.

Végül a célnak visszaútra van szüksége az ügyfélkészlet felé, vagy a tervnek szándékosan le kell fordítania a forrásokat. Ha a cél fordított forgalmat lát, ellenőrizze a fordított forrást; ha a terv megőrzi a készletet, ellenőrizze azt a készletet a visszaútvonalon és a hozzáférési szabályokban. A NAT hozzáadása előtt, hogy eldöntse, melyik tervet szeretné, elrejt egy hiányzó útvonalat, és megváltoztatja a szabályzatot, amelyet a cél lát.

Linux-átjárón a kernel továbbítása a vendégkonfiguráció része. A pfSense-eszköznek saját megfelelője van, és egy Linux sysctl parancs átmásolása bele nem a megfelelő lépés.

Ellenőrizze abból az ügyfélből, amelynek hozzáférésre van szüksége

Egy VPN-ügyfélből teszteljen egy célzott szolgáltatás felé, ne magából az átjáróból. Az átjárón indított kapcsolat más forrást használ, és soha nem gyakorolja az imént engedélyezett továbbítási szabályokat.

Rögzítse a tulajdonságot abban, ami az eszközt kezeli. A kézzel javított VM addig működik, amíg a következő cseréje csendesen vissza nem hozza az eredeti beállítást, és ez a hiba a VPN-szoftver regressziójának fog tűnni.

A munka sorrendje: olvassa ki a tulajdonságot, exportáljon és szerkesszen egy sort, ellenőrizze NO_EFFECT-tel, alkalmazza REFRESH-sel, erősítse meg, hogy a vendég továbbít, majd teszteljen egy ügyfélből.