A forrás/cél ellenőrzés egy kapu, nem a teljes VPN-útvonal

A VPN egy EC2-példányon végződik, elérheti annak a példánynak a tunelcímét, és a forgalom, amelynek azon keresztül egy másik privát hoszthoz kellett volna jutnia, eltűnik. Ez két különböző teszt, és összekeverésük órákat pazarol. Az első azt kérdezi, elérheti-e a példányt; a második azt kéri, hogy továbbítson forgalmat egy olyan cél felé, amely nem a sajátja, ami Linux-továbbítást, tűzfal-szabályzatot, egy útvonalat a túloldalon és egy AWS-szintű engedélyt igényel, amelynek semmi köze a vendég operációs rendszerhez. Semmi nem hívja fel a konzolon a figyelmet erre a különbségre. A tünet útvonal-hibának látszik, és általában nem az.

Válassza szét a két tesztet, mielőtt bármit megváltoztat

Az átjáró elérése bizonyítja a tunelt, a címéhez vezető útvonalat és azt a biztonsági csoportot, amely engedélyezi a cserét. Egy másik hoszt felé történő továbbítás ebből semmit nem bizonyít: más forráscímet, más célt és olyan szerepben lévő példányt használ, amelyre nem feltétlenül épült. Írja le a két tesztet külön, és jegyezze fel, melyik hiúsul meg, mert mindegyik javítása más konzolon található. Egy csak tunelék lezárására épített átjárópéldánynak nincs oka másra továbbítani, és az alapértékei ezt tükrözik. Ezért a második tesztnek saját beállításra van szüksége, nem pedig az első kisebb módosítására.

A ping, amely az átjáróig működik, és a ping, amely a mögötte lévő hosztig meghiúsul, nem időszakos probléma. Ez az elvárt viselkedése egy példánynak, amelynek nem mondták meg, hogy továbbíthat.

Írja le az útvonalat, mielőtt beállításhoz nyúl

Rögzítse az ügyfél előtagját, a továbbító példányt vagy hálózati interfészt, a cél alhálózatot és a válaszútvonalat. A VPC útvonaltáblájában egy példányra mutató bejegyzés nem konfigurálja a példány operációs rendszerét továbbításra, és a továbbítást engedélyező vendégkernel nem hoz létre VPC-útvonalat. A kapcsolat mindkét végének léteznie kell, és azokat különböző helyeken, különböző hozzáféréssel rendelkező emberek szerkesztik.

Ezután vizsgálja meg a forrás/cél ellenőrzés beállítását a tényleges továbbító komponensen, nem a VPC minden példányán. Az AWS dokumentálja, miért kell a mások forgalmát továbbító példánynak ezt az ellenőrzést kikapcsolva tartania, és azt is, miért példányonkénti döntés a beállítás, nem pedig VPC-szintű alapértelmezés.

Négy határ, és az ellenőrzés csak egy közülük

Kezelje az útvonalat négy kérdésként, és válaszoljon rájuk sorrendben. Az elsőként meghiúsuló válasz mutatja, hol van a munka, és a többi egyike sem pótolja.

A sorrend számít, mert az ellenőrzés olcsó: az útvonalak egy oldalon láthatók, az ellenőrzés egyetlen attribútum, és a cél véleménye általában az utolsó dolog, amiről bárki kérdez.

A fordítás megváltoztatja, melyik forrást látja a cél

A routolt kialakítás megőrzi az ügyfél forráscímét, ezért a célnak visszaútvonalra van szüksége az ügyfél előtagjához. A fordított kialakítás ehelyett az átjáró címét mutatja, ami megszünteti ezt a követelményt, és egy állapottáblával helyettesíti az átjárón. A szándékolt architektúra szerint döntsön, ahelyett hogy fordítást adna hozzá, mert egy nem kapcsolódó példa használta, és működni látszott.

Ha fordít, korlátozza a szabályt az ügyfél előtagjára és a szándékolt célra. Ha megőriz, erősítse meg, hogy a túloldal valóban ismeri az útvonalat, ahelyett hogy feltételezné, megtanul egyet.

Az eredeti ügyféltől teszteljen, majd tartsa meg a változtatást

Az átjárón létrehozott kérés sikerülhet, miközben egy továbbított kérés meghiúsul, mert más forrás és más továbbítási eset. Célzott javítás után ismételje meg pontosan azt az ügyfél-erőforrás tesztet, amely meghiúsult, ugyanattól az ügyféltől, és erősítse meg, hogy a válasz visszaérkezik, nem csak azt, hogy a kérés megérkezett.

Végül tegye a beállítást az átjáró kezelt konfigurációjába, hogy egy cserepéldány megkapja. A kézi kivételtől függő sikeres teszt olyan teszt, amely a következő újraépítéskor lejár, és aki felfedezte, nem lesz ott, hogy emlékezzen, miért.