Miért működik az egyik VPN-erőforrás, és miért fut ki a másik az időből

Az egyik privát szolgáltatás betöltődik az alagúton, a következő viszont kifut az időből, és a kísértés az, hogy az egész kliensprofilt újraépítsük. A működő szolgáltatás kontrollként hasznosabb, mint az elölről kezdés okaként. Azt bizonyítja, hogy egy célállomás, egy port és egy engedélyezési útvonal teljesült, és semmi több.

Ugyanazon az átjárón két szolgáltatás érhető el különböző címcsaládokon, különböző alhálózatokon és különböző szabályzaton keresztül.

Válassza szét a működő folyamatot a sikertelenről

Tekintse minden szolgáltatást a saját folyamatának, és ne a VPN tünetének. Egy szemléltető kliens megnyithatja a portal.corp.example címet a 172.20.4.15:443 címen, és mégis elbukhat egy adatbázis elérésében a 172.20.9.40:5432 címen, mert azok két célállomás két szabálykészlettel. Írja fel mindkét sort, mielőtt bármit módosít, a portot és a protokollt is beleértve, mert az a szabály, amely TCP 443-at enged egy hoszton, semmit nem mond a TCP 5432-ről ugyanazon a hoszton.

A sikertelen sor az, amit vizsgálni kell. A működő sor csak azt mondja meg, hol van az alapvonal, és minden változtatás után ez lesz az összehasonlítási pont.

A címeket hasonlítsa össze, mielőtt a neveket hasonlítaná

Oldjon fel minden teljes nevet azon szabályzat szerint, amelyet az alkalmazás valóban használ, majd jegyezze fel a választott címcsaládot. Az egyik név IPv6-címet adhat vissza, míg a másik IPv4-et, és egy régi gyorsítótárazott válasz olyan nyilvános címre küldhet kérést, amelynek semmi köze a privát szolgáltatáshoz.

ip route get 172.20.4.15
ip route get 172.20.9.40
ip -6 route get 2001:db8:60::20

A keresés egy szűk kérdésre válaszol: melyik útvonalat választaná ez a hoszt ehhez a célhoz, a jelenlegi táblák és szabályzati szabályok mellett. A 172.20.4.0/24 útvonala nem fedi le a 172.20.9.0/24 címet, és egy második hálózatkezelő vagy egy jobb specificitású helyi útvonal csendesen felülírhatja az alagutat. Ismételje meg a keresést a névtéren belül, vagy azzal a jelöléssel, amelyet az alkalmazás használ, ha azok eltérnek a héjétól. Jegyezze fel azt az interfészt is, amelyen a csomag elhagyja a rendszert, mert az útvonaltábla egy interfészt nevezhet meg, míg a házirend-alapú útválasztás egy másikon küldi ki a folyamatot.

Az egyező útvonal szükséges feltétel, nem engedély. Azt mondja meg, hogy a csomagnak van hová mennie, és semmit arról, hogy egy tűzfal, egy engedélyezési szolgáltatás vagy maga a hoszt elfogadja-e.

Protokoll és válaszszakasz megmutatják, hol áll meg

A ping-válasz nem bizonyítja, hogy egy adatbázis-port nyitva van, és egy sikeres HTTPS-oldal nem engedélyez fájlmegosztást ugyanazon a gépen. Jegyezze fel, mi jött vissza valójában, ahelyett hogy minden hibát egy kategóriába laposítana. Az időtúllépés, az alaphelyzetbe állítás, a TLS-identitáshiba és az alkalmazásszintű elutasítás mind más-más rétegre mutat.

A megkülönböztetés fontos, mert a javítások szétválnak. A csend általában útvonal-, tűzfal- vagy fordítási problémát jelent az úton. Az azonnali alaphelyzetbe állítás arra utal, hogy valami elérte a hosztot és elutasította a portot. A tanúsítványhiba azt jelenti, hogy a kapcsolat megérkezett, és a név nem egyezett, ami konfigurációs probléma, nem elérhetőségi. Az alkalmazás elutasítása azt jelenti, hogy a hálózat elvégezte a dolgát, és az identitást utána utasították el.

Amikor egy erőforrást átjárón keresztül tesznek közzé, hasonlítsa össze a cél által látott forráscímet azzal a forrással, amelyet a kliense használni vél. Az átjáró által indított kérés sikerülhet, miközben ugyanaz a kérés egy kliensről meghiúsul, mert a kettő különböző címekről érkezik és különböző szabályokkal találkozik.

Módosítson egy változót, és futtassa újra mindkét kérést

Az identitás az utolsó hely, ahová az emberek néznek, és az első, ahol a helyes elutasítás megjelenik. A VPN-bejelentkezés, a könyvtárcsoport és az alkalmazásfiók három különálló identitás, amelyek szétválhatnak. A portálhoz való hozzáférés soha nem jelent hozzáférést a mögötte lévő adatbázishoz, és az egyik könyvtárban lévő név nem hoz létre sort egy másikban. Ha a szolgáltatás a felhasználó tervezett hatókörén kívül esik, az elutasítás a rendszer működése.

Kérje meg az erőforrás tulajdonosát, hogy erősítse meg a tervezett jogosultságot, ahelyett hogy széles útvonalat adna hozzá, vagy egy csoportot tesztként megnyitna. A hálózat kiszélesítése egy állítás bizonyítására az az út, amelyen egy ideiglenes diagnosztika állandó kitettséggé válik, és tönkreteszi azt a kontrollt, amellyel elkezdte. Iterációnként egy bizonyított eltérés elegendő: hiányzó útvonal, rossz címcsalád, blokkolt port vagy hiányzó csoporttagság.

Minden változtatás után ismételje meg mindkét kérést, és tartsa egymás mellett a kimeneteket. A vizsgálat akkor ér véget, amikor a sikertelen szolgáltatás a saját szabályzata szerint működik, miközben a működő szolgáltatás és a még várt elutasítások pontosan úgy viselkednek, mint korábban.