A működő kiszolgálókonfiguráció átmásolása, néhány cím kicserélése és ezt fióktelep-profilnak nevezni általában létrehoz egy kapcsolatot. Ez a legrosszabb kimenet, mert a fióktelep ezután rossz szereppel fut, olyan anyagot tár fel, amelynek nem kellene elhagynia a hubot, és olyan útvonal-társítást hagy maga után, amelyre senki nem emlékszik, hogy létrehozta. A kapcsolat egyszerre három problémát rejt el, és az alagút feljön, mielőtt bárki ellenőrizné őket.

A fióktelep saját identitással és hálózati szereppel rendelkező partnerként kezelése az, ami helyessé teszi a profilt. A javítás nem egy jobb másolat, és az oldal többi része arról szól, mit kellene egy kliensnek valójában tartania.

Két szerep, amely egy fájlnak látszik

TLS módban a két fél feladata kiegészíti egymást. Az egyik oldal figyel, birtokolja a kiszolgáló tanúsítványát és kulcsát, és eldönti, mely kliensek csatlakozhatnak. A másik oldal kezdeményez, ellenőrzi a figyelőt, és bemutatja saját identitását.

Egy kiszolgálófájl olyan utasításokat tartalmaz, amelyeknek kliensen nincs értelme: kötési cím és port a figyeléshez, címtartomány kiosztáshoz, és gyakran push-lista azokhoz a beállításokhoz, amelyeket a klienseknek meg kellene kapniuk. Ezek átmásolása egy fióktelepre olyan eszközt hoz létre, amely egyszerre próbál figyelő és kliens lenni.

A titkos kulcs a legfontosabb rész. Egy kliens soha nem hordozhatja a kiszolgáló titkos kulcsát, és a CA aláírókulcsára sem szorul rá. A CA-tanúsítvány nyilvános bizalmi anyag; az aláírókulcs ahhoz a helyhez tartozik, ahol a tanúsítványokat kiadják.

Mit kell tartalmaznia egy fióktelep-profilnak

Egy fióktelep-profilnak kell a távoli végpont és az átvitel, a megbízható kiszolgálóidentitás, a fióktelep saját tanúsítványa és kulcsa, valamint azok az útvonalak és DNS-beállítások, amelyekre a fióktelepnek tényleg szüksége van. Semmi más nem kötelező.

Tartsa külön a fióktelep identitását helyszínenként. Két fióktelep egy tanúsítványon azt jelenti, hogy az egyik visszavonása kikapcsolja a másikat, és a hub naplói nem tudják megkülönböztetni őket. A helyszínenkénti identitás az, ami mind az auditnyomot, mind a visszavonási történetet működteti.

Legyen óvatos az eszközök munkafolyamataival. A pfSense Client Export csomagja a megfelelő Remote Access környezetekhez készít profilokat, és kiszolgálólistája csak a Remote Access módban beállított kiszolgálókat tartalmazza. Egy másik módú telephely-telephely kiszolgáló nem jelenik meg, és ez a hiány információ, nem meghívás a kiszolgáló titkainak másolására.

Ha az eszköz nem exportálja a szükséges profilt, használja a dokumentált telephely-telephely kliens munkafolyamatát, vagy építse fel a profilt a telepített kiadás támogatott példájából. Csak akkor exportáljon kiszolgáló-mentést a fióktelepre, ha a terv egy kiszolgáló helyreállítása, ami nem áll fenn. A mentés a hub titkos anyagát is hordozza, ezért egy mentés áthelyezése a fióktelepre kulcskezelési döntés, nem fájlátvitel. Tartsa a hubon, és a kliens identitását ott hozza létre, ahol a tanúsítványokat kiadják.

A partner és a hálózat közötti társítás külön áll

Egy sikeresen csatlakozó fióktelep-kliens még nem tud forgalmat átengedni a LAN-ja számára, amíg a hub nem tudja, hogy ez a partner birtokolja azt a prefixet. Ez a társítás a hubon él, a kliens identitásához kötve, és külön áll a fióktelep saját, a távoli hálózatok felé vezető útvonalától. Nélküle a fióktelep hosztjai elérhetőnek látszanak az alagút statisztikájában, és a gyakorlatban elérhetetlenek. A hub naplója az a hely, ahol megerősíthető, hogy a társítás alkalmazásra került-e.

Egy útvonal hozzáadása a hub operációs rendszerében nem ugyanaz, mint megmondani az OpenVPN-nek, melyik kliens birtokolja a prefixet. Kliensenkénti társítás nélkül a csomag eléri az alagút interfészét, és eldobódik, mert egyetlen partner sem igényli a célt.

A fióktelep oldalán a megfelelő igény egy útvonal azok felé a hálózatok felé, amelyeket el kell érnie, plusz egy LAN-útválasztó, amely tudja, hogyan küldje vissza a forgalmat a fióktelepre. A kiszolgáló oldali tulajdon és a kliens oldali célútvonalak külön objektumok, és egy működő alagút csak az első ugrást bizonyítja. Írja le mindkettőt a fióktelep átadási jegyzetébe, mert a következő mérnök csak az egyiket fogja megtalálni.

Annak bizonyítása, hogy a fióktelep az a partner, akire gondol

Az identitást a forgalom ellenőrzése előtt ellenőrizze. A hub naplójának mutatnia kell a fióktelep tanúsítványának közhasználatú nevét, és a kliens által kapott címnek meg kell felelnie a szándékolt címkészletnek vagy fix hozzárendelésnek. Ha a napló más nevet mutat, a profil valaki más identitását hordozza.

Ezután ellenőrizze a társítást úgy, hogy egy kérést küld a fióktelep egyik hosztjáról a hub oldali erőforrásra, és erősítse meg, hogy a várt forrás-címmel sikerül. Teszteljen egy olyan célt, amelyet a fióktelep nem érhet el, és erősítse meg, hogy meghiúsul, mert egy véletlenül működő megengedő útvonal nem ugyanaz, mint egy helyes házirend.

Végül vonja vissza a fióktelep identitását, és erősítse meg, hogy a kapcsolat meghiúsul, miközben a hub saját tanúsítványa és a többi helyszín tovább működik. Ha a visszavonás töri a hubot, a szerepek és identitások valahol megosztottak voltak, és ez az a lelet, amelyet érdemes visszavinni a tervezésbe.

Egy kész fióktelep dokumentált identitással, csak kliensnek szóló profillal, a hubon lévő partner-hálózat társítással és kipróbált visszaúttal rendelkezik. Egy kiszolgálófájl szövegének megfordítása ezek egyikét sem adja meg.

Kapcsolódó cikkek