Miért igényel új végpontot a Client VPN-tanúsítvány újraimportálása

Egy Client VPN-kapcsolat megszakad, az ACM-ben lévő tanúsítvány kicserélődik, és semmi sem változik. A tanúsítványobjektum soha nem az volt, amit a végpont használt. A végpont létrehozásakor eltárolja a tanúsítványhoz fűződő társítást, valamint az ügyfél-CA-t, amelyhez validálni fog, a hitelesítés típusát, az alhálózatokat és az engedélyezési szabályokat, és e társítások egyikéhez sem tartozik olyan módosító hívás, amely elfogadna egy helyettesítő tanúsítványt. Az ARN mögötti bájtok cseréje a tanúsítvány változása, nem azé a végponté, amely rögzítette.

A végpont hivatkozásokat tárol, nem tanúsítványokat

A mechanizmust érdemes pontosan megfogalmazni, mert az egész hibát megmagyarázza. A create-client-vpn-endpoint egy kiszolgálótanúsítvány ARN-jét és egy ügyfél gyökértanúsítvány-lánc ARN-jét veszi át, és az így létrejövő végpont ezeket a hivatkozásokat a hitelesítési beállításokkal együtt rögzített tulajdonságként őrzi. Az API nem kínál olyan műveletet, amely lecserélné a kiszolgálótanúsítványt egy meglévő végponton.

A kötést találgatás nélkül is megerősítheti. A aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 kiírja a tanúsítvány ARN-jét, az ügyfél gyökérláncának ARN-jét, a hitelesítés típusát, az ügyfél CIDR-jét és a kapcsolódó alhálózatokat, ami azoknak a tulajdonságoknak a teljes halmaza, amelyeket reprodukálnia kellene. Futtassa újraimportálás előtt és után, és a kimenet nem mozdul. Ez a bizonyíték arra, hogy az újraimportálás soha nem segíthetett.

Miért nem érheti el az újraimportálás a végpontot

Az újraimportálás új tanúsítványtörzset ír egy meglévő ARN alá. Ez jogszerű művelet, ha a tanúsítvány közel jár a lejárathoz, és az ACM elfogadja, amíg a titkos kulcs egyezik és a lánc validál. Amit viszont nem tesz, az a végpont létrehozásakori validálás újrafuttatása, így a társítás és a mögötte lévő anyag úgy marad, ahogy a végpont építésekor volt.

Ezért is hangzik a tünet hálózati hibának. A TLS-kézfogás még az engedélyezés értékelése előtt meghiúsul vagy visszaáll, így a biztonsági csoportok, az útvonalak és az engedélyezési szabályok mind ártatlannak tűnnek, és azok is.

A lánc az ügyféltanúsítvány része

A hiba második fele az ügyféltanúsítványban van, és könnyebb elutasítani. Az ügyféltanúsítványt az azt kiállító lánccal együtt kell importálni, pedig az importálási űrlap ezt a mezőt opcionálisként mutatja. A lánc nélkül a végpont nem tud utat építeni az ügyféltanúsítványtól ahhoz az ügyfél-gyökér-CA-hoz, amellyel konfigurálták, és a kapcsolat egy puha visszaállításba torkollik, ami úgy hangzik, mint egy csomagokat eldobó tűzfal. A openssl verify -CAfile root-ca.pem client.crt ezt a kérdést helyben, egy másodperc alatt megválaszolja, és ennek kellene lennie az első parancsnak, amit futtat.

Az újraimportálás a lánccal valódi javítás arra a felére, és önmagában még mindig nem elég. Amint az ACM-objektum megváltozott, a régi társítást őrző végpont a rossz dolog, amely ellen tovább tesztelni. Mindkét lépés ugyanahhoz a javításhoz tartozik, ezért a kétrészes javítás nem ellentmondás.

A végpont újralétrehozása migráció

A helyettesítő végpont létrehozása migráció, nem újbóli próbálkozás, és úgy kezelni, mint újbóli próbálkozást, az az út, amelyen a csapatok két félig konfigurált végponttal végzik. Az új végpont új ID-t kap, és ha nem tervezte meg, minden felhasználónak új DNS-nevet. Tartsa az ügyfélprofilt név felé mutatva cím helyett, hogy a csere rekordmódosítás legyen újraelosztás helyett.

A biztonságot adó sorrend rövid: hozza létre az új végpontot ugyanazzal a CIDR-rel, alhálózatokkal és engedélyezési szabályokkal, exportáljon friss profilt a aws ec2 export-client-vpn-client-configuration segítségével, és ellenőrizze egy felhasználóval. Csak ezután kerül le a régi végpont.

A régi végpont kivonásának megvan a maga sorrendje. Vonja vissza azokat az ügyféltanúsítványokat, amelyeket ki akart vonni, mielőtt törli, mert egy új végpont, amely még mindig bízik a régi CA-ban, továbbra is elfogadja azokat a tanúsítványokat, amelyekről azt hitte, eltűntek. Ezután törölje a régi végpontot, és távolítsa el az engedélyezési szabályait, hogy egy elavult profil ne tudjon újra csatlakozni egy célhálózathoz, amelyről azt hitte, zárva van. Írja be a régi végpont ID-jét és a társítások azonosítóit a változási rekordba, mert a memóriához hasonlított migráció az az út, amelyen egy működő végpont kétszer újraépül.

Rendezze a diagnózist

Válasszon szét három hibát, mielőtt bármilyen konfigurációt módosít. Az ügyfél nem tudja befejezni a TLS-t, az ügyfél befejezi a TLS-t és nincs engedélyezve, vagy az ügyfél csatlakozik és nem ér el egy célt. A tanúsítvány-társítás az elsőhöz tartozik, egy engedélyezési szabály, amely nem fedi le az ügyfél címét, a másodikhoz, az útvonal vagy biztonsági csoport pedig a harmadikhoz, ahol a végpont újralétrehozása szinte mindig rossz lépés.

Egy végpont, amely hónapokig működött, majd megállt, tanúsítvány- vagy házirend-változás nélkül, önálló eset. Az azonos beállításokkal való újraépítés helyreállíthatja a szolgáltatást, de ez érv amellett, hogy a konfiguráció reprodukálható maradjon, nem pedig érv amellett, hogy minden incidensnél újraépítsük.

Tartson négy dolgot verziókövetés alatt, hogy a következő újraépítés diff legyen, ne rögtönzés: a végpont paraméterei, a tanúsítvány és a lánc ARN-jei, az engedélyezési szabályok és az ügyfél CIDR-je. A Client VPN hitelesítési dokumentációja felsorolja, melyik tanúsítvány milyen szerepet játszik, amit érdemes ellenőrizni, mielőtt egyáltalán feltételezné, hogy a tanúsítvány a probléma. Ha az újraimportálás semmit nem változtat, és a végpont továbbra is visszaáll, a társítás a gyanús, és a válasz egy új végpont a rögzített paraméterekből felépítve. Ha a végpont mégis felveszi az új objektumot, a társítás már helyes volt, és a hiba az ügyfél láncában vagy az engedélyezési rétegben van.