Site-to-site VPN AWS és Azure között: először a visszaútvonalat írja le

Az alagút fel fog jönni. Ez általában így van, mert az IKE csak egyező javaslatokat és elérhető partner-címet igényel. Ami utána elbukik, az a visszaút: az AWS számítási feladat csomagokat küld egy alagútba, de az Azure oldalán semmi nem tudja, hogyan válaszoljon a 10.10.0.0/16-ra, vagy az Azure-útvonal olyan táblában van, amelyet a számítási alhálózat nem használ. Írja le az útvonaltervet, mielőtt bármelyik konzolhoz nyúlna, és az alagút lesz a munka legkevésbé érdekes része.

1. lépés: fagyassza le a címtervet

Konkrét értékekkel dolgozzon. Egy AWS számítási feladat a 10.10.1.20 címen van a 10.10.0.0/16-on belül, és TCP 443-at igényel a 10.20.0.0/16-on belül, a 10.20.1.30 címen futó Azure-szolgáltatás felé. A két tartomány nem fedhet át, és az átvételi teszt a szolgáltatáspár, nem az alagút.

Ezt a négy tényt minden más előtt írja le, mert minden későbbi lépés ezekhez mérten ellenőrződik.

2. lépés: nevezze meg az átjárót, amely mindkét véget birtokolja

Az AWS Site-to-Site VPN végződhet virtuális privát átjárón vagy tranzit átjárón, és ezek különböző útválasztási tulajdonosok. Az Azure kínálja a felügyelt VPN Gateway-t és külön, az ügyfelek által maguk futtatott VM-alapú készülékeket. Jegyezze fel, melyik párja van, mert a következő ugrás minden kombinációban más.

Felügyelt átjárónál ne másoljon olyan útvonalat, amely egy feltételezett privát készülékcímre mutat. Készüléknél ne feltételezze, hogy a felhőbeli útvonalterjesztés beállítja a vendég operációs rendszert, mert nem teszi.

Az itteni hiba olyan tervet ad, amely teljesnek látszik, és csomagokat küld egy címre, amely soha nem válaszol.

3. lépés: írja le, melyik útvonalat használja valóban az egyes számítási feladatok

Az alábbi minden határ külön keresés, és az egyikben lévő útvonal nem útvonal a csomag számára. Töltse ki a táblázatot saját értékeivel, mielőtt az alagút élesbe kerül.

AWS-ben a számítási alhálózat útvonaltáblája az Öné, még akkor is, ha a BGP vagy az alagút egészséges; az útválasztási áttekintés ezt a kapcsolat részének tekinti. Azure-ban a felhasználó által meghatározott útvonaltábla alhálózathoz kapcsolódik, nem a virtuális hálózathoz, ezért az effektív útvonalat a számítási feladat NIC-jén ellenőrizze, nem a VNet panelen.

A felügyelt Azure-átjáró az átjáró-terjesztés révén megtanulhatja a távoli előtagot, és egy UDR felülbírálhatja ezt a döntést. Az UDR-t akkor adja hozzá, ha oka van rá, nem reflexből. Ha hozzáadja, a készülékcím kitalálása helyett arra a következő ugrásra irányítsa, amelyet az átjáró a VPN-útvonalhoz közzétesz. Ezután olvassa újra az effektív útvonalakat a NIC-en, mert a döntés valójában ott születik.

4. lépés: hangolja össze a hatókört

BGP esetén hasonlítsa össze, mit hirdet az egyik fél azzal, amit a másik ténylegesen megtanult, előtagról előtagra. Statikus útválasztásnál hasonlítsa össze a beállított távoli tartományokat a 3. lépésben leírt számítási útvonalakkal.

Az IKE-kapcsolat, amely egyetért a kriptográfiában, nem bizonyítja, hogy bármelyik fél megtanulta a 10.10.0.0/16-ot vagy a 10.20.0.0/16-ot. Két alagút állhat, miközben az egyik fél egyetlen /24-et hirdet a tervezett /16 helyett. Az előtagot az útválasztási táblában ellenőrizze, nem az alagút állapotában. Az eltérés később egy működő és egy soha nem válaszoló alhálózatként jelenik meg.

5. lépés: a valódi forrásból tesztelje a szolgáltatást

Engedélyezze a szándékolt forgalmat az AWS biztonsági csoportjaiban és hálózati ACL-jeiben, az Azure NSG-iben és az útvonal bármely készülékszűrőjében. Ezután nyisson egy kapcsolatot a 10.10.1.20-ról a jóváhagyott szolgáltatáscímre és portra, és erősítse meg, hogy a válasz ugyanarra a forrásra tér vissza.

A felhő biztonsági csoportjai és az NSG-k is állapottartók, ezért az elutasított visszacsomag útválasztási tünet, nem pedig egy szabály, amelyet elfelejtett visszafelé megírni.

Egy ping bármelyik átjáróról nem dönt el semmit. Az ICMP egy átjárócímre a vezérlősík útvonalát gyakorolja, nem a továbbított TCP-szolgáltatást, amelyre a számítási feladatnak szüksége van.

Visszaállítás és nyilvántartás

Jegyezze fel az útvonaltulajdonosokat az alagút-azonosítók mellé, és őrizze meg a változás előtti útvonaltáblákat. Ha a változást ki kell venni, az alagút bontása előtt távolítsa el a számítási útvonalakat, hogy ne maradjon alhálózat egy már nem létező következő ugrásra mutatva.

Így egy későbbi alhálózat-áthelyezésnek vagy spoke-csatlakozásnak egy meghatározott helye van a frissítésre, ahelyett hogy egy működő alagút viselné egy olyan útvonal hibáját, amely soha nem volt az övé.