Hogyan tervezzünk illeszkedő VPN-kliens címtárat
Válassza ki a címtárat a kiszolgáló mezőjében, majd olvassa le a címet, amelyet az ügyfél ténylegesen kap, kövesse vissza a választ, és jegyezze fel a tartományt, módot, útvonalat és DNS-hatókört.
A VPN-kiszolgáló címtármezőjénél kezdje, ne egy táblázatban. Amit oda beír, az lesz minden később csatlakozó ügyfél belső címtere, és együtt kell léteznie azzal a LAN-nal, amelyet ezek az ügyfelek elérnek, a mögötte lévő útvonalazott helyszínekkel és minden címmel, amelyet az ügyfél otthon már birtokol. Csatlakoztasson egy ügyfelet, amint a címtár mentésre került, mert az az első kapcsolat megmondja, hogy az érték a gyakorlatban működik-e. Innen a bejárás kifelé halad: az ügyfél által kapott cím, az útvonal, amelyet egy válasz bejár, és a feljegyzés, amelyet maga mögött hagy.
A címtármezőnél kezdje, mielőtt bármely ügyfél csatlakozna
Minden termék másképp tárja fel ezt, ezért keresse meg az objektumot, amely valóban címeket oszt ki. Az OpenVPN-nek van egy kiszolgálóoldali címtárutasítása, amely a következő szabad címet adja, az IKEv2-átjárónak van egy a partnerkonfigurációhoz kötött címtárszakasza, a WireGuardnak pedig egyik sincs, mert minden partner a saját címét hordozza a konfigurációs fájljában. A címtárutasítás és a partnerenkénti cím nem cserélhető fel, és a rossz szerkesztése elpazarolja a bejárás hátralévő részét.
Amikor megvan a mező, sorolja fel a már létező tartományokat: az irodai LAN-t, minden útvonalazott helyszínt, a felhő VPC-t és minden más címtárat, amely még üzemben van. Az átfedést előtag-aritmetika dönti el, nem az, hogy a hosztszámok ismerősen néznek-e ki, ezért hasonlítsa össze az összevont tartományt mindegyikkel. Két tartomány, amely mindkettő 10.x-nek látszik, ártalmatlan, ha az összevontjaik nem metszenek, és támogatási eset, ha metszenek.
Ezután döntse el, hogy a cím annak függvénye-e, ki csatlakozik, vagy annak, mikor csatlakoznak. A dinamikus kiosztás azt adja, ami szabad, míg az identitás szerinti kiosztás egy rögzített címet köt egy hitelesítő adathoz. Írja le a választást, mert megváltoztatja, hogy egy újracsatlakozásnak később hogyan kell kinéznie.
Olvassa le a címet, amelyet az ügyfél ténylegesen kapott
Csatlakoztasson egy ügyfelet, és azt olvassa, amit az alagút jelent, ne azt, amit a címtár ígért. Az ügyfél a kapcsolat állapotában mutatja belső címét, Linux alatt pedig az interfész közvetlenül hordozza.
Hasonlítsa össze ezt a címet a mentett tartománnyal. Ha azon kívül esik, más kiosztási útvonalat lát, mint amelyet szerkesztett. Ellenőrizze az előtag hosszát is, mert a /32-t tartó ügyfélnek nincs kapcsolati partnere, és minden célállomást az alapértelmezett útvonalán küld.
ip -4 addr show tun0
ip route get 192.168.50.20
Az az ügyfél, amely otthoni routerről csatlakozik ugyanazzal a tartománnyal, csatlakozni fog, majd szinte semmit nem ér el. Az ügyfél megtartja a helyi útvonalát erre az előtagra, így az alagút címe ütközik a mögötte lévő hálózattal, és a forgalom a rossz interfészen távozik. Ez az eset a kiszolgálón nem javítható; a dokumentált megoldás az otthoni hálózat újraszámozása vagy egy elég távoli címtártartomány választása, hogy az ütközések ritkák maradjanak. Jegyezze fel a hibát és a megoldást is, mert az ügyfélszolgálat újra találkozik vele.
Csatlakoztassa újra ugyanazt az ügyfelet, és figyelje a címet. A dinamikus címtár ugyanazt vagy más értéket adhat vissza, és mindkettő helyes, míg az identitás szerinti címtár, amely megváltoztatja a címet, nem tartja be a kötést. Ez az ellenőrzés másodpercekig tart, és eldönti, hogy az első szakaszban feljegyzett mód-e az érvényes mód.
Kövesse vissza a választ a szolgáltatástól
A címtár csak akkor működik, ha a válaszok vissza tudnak utazni hozzá. A LAN-on lévő szolgáltatás a belső címre válaszol, ezért az átjárójának útvonalra van szüksége a címtárhoz, vagy fordításra a szolgáltatás előtt. Amikor egy kérés az alagúton érkezik, és a válasz más útvonalon távozik, egy állapotkövető tűzfal vagy egy fordított útvonal ellenőrzés eldobja, és az ügyfél egy olyan szolgáltatást lát, amely csatlakozik, majd megakad. Tegye a címtárat az útvonaltervbe egyetlen összevonható blokként, ahelyett hogy hosztonkénti útvonalakat adna hozzá.
A fordítás megváltoztatja, mit lát a rendszer többi része. Amikor a forrás átíródik, a hoszt tűzfalában és az alkalmazásnaplóban lévő cím a lefordított, így a címtár címére írt szabály semmire nem illeszkedik, és egy naplósor nem vezethető vissza egy ügyfélhez. A strongSwan továbbítási dokumentációja lefedi ennek az útvonalnak a kiszolgálóoldali felét egy IKEv2-átjáróhoz. A DNS ugyanezt a korlátot hordozza, mert egy név, amely olyan címre oldódik fel, amelyet az ügyfél nem ér el, később és máshol hiúsul meg.
Két ügyfél, majd egy visszavonás
Csatlakoztasson két ügyfelet egyszerre, és olvassa le mindkét címet. Különbözőnek, használhatónak és a címtáron belülinek kell lenniük, és mindegyiknek el kell érnie a szolgáltatást, amelyre szánják. A duplikált címeket osztó címtár általában itt mutatkozik meg, nem az első együgyfeles tesztben.
Vonjon vissza egy hitelesítő adatot, miközben a másik ügyfél csatlakozva marad, majd próbálja ki a szolgáltatást a túlélő ügyfélről. A másik munkamenetet zavaró visszavonás megosztott állapotra utal, leggyakrabban egy hitelesítő adatra vagy egy címre, amelyet eszközök között újrahasználnak. Csatlakoztassa újra a visszavont ügyfelet, és erősítse meg, hogy elutasítják, ahelyett hogy megkapná a felszabadult címet.
Fejezze be egy célállomással, amelyet meg kellene tagadni. Az az ügyfél, amely mindent elér, csatlakozott, nem tesztelt.
Írja le a négy értéket oda, ahol a következő változás megtalálja őket
A feljegyzés rövid: a címtártartomány és előtag, a kiosztási mód, a visszaút vagy a használatban lévő fordítás, és a DNS-hatókör, amely ezekre a célokra válaszol. Tegye a kiszolgálókonfiguráció mellé, ne egy jegybe, és lássa el dátummal. Aki később a négy közül egyet megváltoztat, annak szüksége van a másik háromra maga előtt, mert a címtár átméretezése megtöri az útvonalat, az útvonal változása pedig megtöri a DNS-választ.
Tartsa mellette a tulajdonosi megjegyzést: az alagút tartománya a VPN-kiszolgálóé, és a LAN DHCP-tartományában tett foglalás semmit nem foglal le az alagúton belüli ügyfélnek. Ez az egy sor előzi meg a leggyakoribb újramunkát, amikor valaki hozzáad egy foglalást, és azt várja, hogy az alagút címe követi azt.