Az AWS Client VPN-en keresztül csatlakozó laptop probléma nélkül eléri az EC2-n futó alkalmazást. Aztán fordítva próbálod, EC2-ből a kliensnek kiosztott címre, és a kapcsolat lefagy vagy elutasítja. Ez az aszimmetria ritkán hiányzó biztonsági csoportszabály. A VPC alhálózataihoz kapcsolt Client VPN-végponton az AWS az IPv4 kliensforrásokat a végpont hálózati interfészére fordítja, így nincs olyan bejövő VPC-cím, amely a laptopodat képviselné.

Kezdd azzal, amit a rögzítés mutat

Készíts rögzítést az EC2-gazdagépen, miközben a kliens csatlakozik, és olvasd ki a forrás címet, amelyet az alkalmazás ténylegesen lát. Ha ez a VPC-oldali végpontinterfész, és nem a klienspoolból származó cím, akkor a fordítás igazolva van, mielőtt egyetlen szabályt is módosítanál.

A klienspool kiosztási tartomány, nem visszaútvonalas alhálózat. Ezen a különbségen csúszik el az ilyen vizsgálatok többsége.

A fordítás, amely megmagyarázza az aszimmetriát

Három folyamatot kevernek össze egymással, és csak az egyik az, amit az emberek tesztelnek.

FlowStarted byWhat the VPC seesOutcome
Client to EC2 serviceThe clientA translated source at the endpoint interfaceWorks, with a stateful reply
EC2 host to client pool addressThe EC2 hostA destination with no route and no translation stateNo usable path
Client to clientA client, when the feature is configuredTraffic mediated by the endpointWorks only with that feature and its authorisation

A Client VPN összetevőinek leírása kimondja, hogy az IPv4 kliensforrások a végpont interfészére fordulnak, és ez elég ahhoz, hogy lássuk, miért nincs a középső sornak mihez illeszkednie.

Egy új kapcsolathoz útvonal, címfeloldási lépés és engedélyezési döntés kell. Egy másik fél munkamenetéből származó fordítási állapot egyiket sem adja.

Miért nem új kapcsolat a válasz

A TCP-válasz egy meglévő bejegyzéshez illeszkedik, ezért a visszaút bejövő szabály nélkül is működik. Az EC2-gazdagépről induló friss SYN nem talál illeszkedő bejegyzést, így közönséges kimenő kísérletté válik egy olyan cél felé, amelyet a VPC nem tud elérni.

Ezért félrevezető ezt csak egyirányú forgalomként leírni. A visszaforgalom ezekben a munkamenetekben folyamatosan áramlik. Az útvonal nélküli rész a kezdeményezés.

Mi töri még mindig meg a munkamenetet, amelynek működnie kellene

A biztonsági csoportok, a hálózati ACL-ek és a laptop saját tűzfala mind számítanak azoknál a kapcsolatoknál, amelyeknek sikerülniük kellene. A sikertelen ping mondja a legkevesebbet, mert az ICMP-szabályzat gyakran elválik a téged érdeklő TCP-szabályzattól.

Ezeket a szabályokat a fordított forráshoz írd, ne a kliens címéhez. A hálózaton soha meg nem jelenő címhez kötött szabályok a leggyakoribb ön okozta hiba ebben a tervezésben.

Amikor a VPC-nek valóban el kell indítania a beszélgetést

Ha egy szolgáltatásnak értesítenie kell egy munkaállomást, fordítsd meg az irányt, és hagyd, hogy a kliens tartson fenn egy állandó kimenő csatornát, amelyre a szolgáltatás válaszol. Ha egy egész távoli hálózatnak elérhetőnek kell lennie a VPC-ből, válassz olyan architektúrát, amely közzéteszi a prefixeit és a hozzáférési szabályzatát, ahelyett hogy feltételeznéd, hogy a Client VPN ezt már megteszi. A kliens-kliens hozzáférés egy harmadik, szűkebb eset, saját útvonal- és engedélyezési objektumokkal. Ezek egyike sem csupán egy jelölőnégyzet a meglévő végponton.

Az IPv4-magyarázat hatókörét is tartsd őszintén. A jelenlegi AWS-dokumentáció külön kezeli az IPv6-ot, ahol ez a fordítás nem érvényesül, és más csatlakozási modelleket, amelyek másként irányítanak.

Három címkézett lépésben teszteld: a kliens engedélyezett munkamenetet nyit, a VPC-szolgáltatás válaszol arra a munkamenetre, és egy VPC-gazdagép új munkamenetet nyit a kliens felé. Hogy az első kettő sikerül, a harmadik pedig meghiúsul, ennek a tervezésnek a várt formája, nem tűzfal-szabályokkal üldözendő hiba.

Kapcsolódó cikkek