A félpercenként felálló, majd újrainduló alagút általában nem titkosítási vagy MTU-probléma. Egy identitást használnak kétszer. A kiszolgáló egy ismerős köznapot lát, a legújabbként veszi át az új munkamenetet, és a régebbi eszköz felfedezi, hogy lecserélték. Az ügyfél oldaláról ez tétlenségi időtúllépésnek és újraindulásnak látszik, ezért kezdődik a vizsgálat olyan gyakran rossz helyen.

Kezdje az újraindítási intervallummal

Az intervallum mindenekelőtt nyom. A ping-restart ablakhoz illeszkedő egyenletes ritmus lecserélt munkamenetre utal, nem hibás útvonalra, mert az útvonalhibák ritkán ennyire szabályosak. Jegyezze fel az újraindítások közötti pontos hézagot és az ok sort az ügyfélnaplóban. Az időtúllépést követő újraindítás más történetet mesél, mint egy sikertelen kézfogás.

Ellenőrizze, mikor kezdődtek az újraindítások egy második eszközhöz képest. Az új laptop, a telefon vagy egy tartalék gépre másolt profil a szokásos kiváltó ok, és az időpont általában egybeesik azzal a nappal, amikor valaki beállította.

Írja fel az intervallumot és az okot. Mindkettő bizonyíték, és mindkettő olcsón gyűjthető.

Olvassa el, mit mondott a kiszolgáló a második bejelentkezésről

A saját kiszolgálón a napló megnevezi a köznapot, és mutatja a második érkező kapcsolatot. duplicate-cn nélkül ez az érkezés lecseréli az ugyanahhoz a névhez tartozó meglévő munkamenetet, és az üzenet ezt általában nyíltan ki is mondja. duplicate-cn esetén a két munkamenet együtt létezik, és a tünet megváltozik: az ügyfelek kapcsolatban maradnak, de egy közös ügyfél-beállításkészletet és egyetlen visszavonási döntést osztanak meg. Olvassa együtt a két bejegyzést, mert a csere csak sorrendben látható.

Tárolt szolgáltatásnál lehet, hogy egyáltalán nincs kiszolgálónaplója. A nyom ilyenkor az időzítés: egy stabil alagút, amely minden alkalommal leesik, amikor egy másik gép csatlakozik, és az ügyfélnaplóban nincs más az időtúllépésen kívül.

Hasonlítsa össze a tanúsítvány- és kulcsblokkokat mindkét profilban, ne csak a távoli gépnevet. A másolt profilok általában csak a fájlnévben különböznek.

Válassza szét az identitást a kiszolgáló oldalán

Adjon ki egy tanúsítványt eszközönként azon CA révén, amely ehhez a kiszolgálóhoz ír alá. Az Easy-RSA esetében ez külön ügyfélnevet jelent minden eszközhöz, és a profil ezután abból a tanúsítványból és annak kulcsából épül fel. A köznapból az eszköz identitása lesz, és pontosan ez hiányzott a kiszolgálónak. Az eszközről nevezze el őket, ne a személyről, hogy a csere új nevet hozzon létre.

A megosztott vezérlőcsatorna-kulcs külön dolog. A tls-crypt vagy tls-auth minden ügyfél vezérlőcsatornáját védi, és megosztásra készült. Ez nem ügyfél-identitás, és a cseréje nem javítja meg a duplikált tanúsítványt.

Tartsa a tanúsítványt, a kulcsot és minden ügyfélszintű konfigurációs fájlt ugyanazon köznap alatt, különben a leképezés eltörik a következő kapcsolatnál. Az ottani eltérés olyan ügyfelet hoz létre, amely hitelesít, majd semmit nem kap.

Tartsa összhangban a címeket és a beállításokat a szétválasztás után

A fix címek második ütközési módot hoznak be. Ha a kiszolgáló őket a ifconfig-pool-persist vagy ügyfélszintű fájl révén osztja ki, ezek a rekordok még mindig a régi névre mutatnak. Két eszköz ugyanazt az alagútcímet kaphatja, még a tanúsítványok szétválasztása után is, és ez a hiba másképp néz ki, mint az eredeti hurok.

Frissítse a leképezést a tanúsítvánnyal egy időben, majd csatlakoztassa újra mindkét eszközt, és hasonlítsa össze a kapott címeket. A duplikált cím szakaszos veszteségként jelenik meg, nem tiszta újracsatlakozásként.

Az eszközönként eltérő beállításokat az adott eszköz saját fájlján keresztül küldje, ne közös sablonon át. A közös sablon a következő duplikátumot is nehezebben észlelhetővé teszi.

Vonja ki rendesen a régi identitást

Vontassa vissza a tanúsítványt, amikor a hardvert kivonják vagy eltűnik, ahelyett hogy törölné a profilt a régi gépről. A visszavonás új CRL-t állít elő, és a kiszolgálónak arra a fájlra van szüksége, ahová a crl-verify mutat. Ezzel az irányelvvel a helyén egy hiányzó vagy olvashatatlan CRL miatt a kiszolgáló minden ügyfelet elutasít, ezért minden frissítés után teszteljen egy ismert fiókot.

Vezessen olyan leltárt, amely minden tanúsítványt személyhez vagy eszközhöz köt, kiadási és visszavonási dátumokkal. Ez a leltár fájlnevek olvasása nélkül megválaszolja, kinek van még hozzáférése, és megakadályozza, hogy a következő másolt profil újraindítsa a hurkot.

Kapcsolódó cikkek