Statikus OpenVPN IP kliensenként: ifconfig-push, nem ipp.txt

Egy sor szerkesztése az ipp.txt fájlban címfoglalásnak tűnik, de nem az. Ez a fájl, amelyet a ifconfig-pool-persist nevez meg, rögzíti, hogy egy közös név legutóbb melyik címmel rendelkezett, hogy a készlet visszaadhassa ugyanazt, amikor ez kényelmes. Semmi sem köti benne a következő kapcsolatot ehhez a számhoz.

Hajtsa végre az alábbi ellenőrzéseket sorrendben. Mindegyik vagy megerősíti a mechanizmust, vagy azt mondja, hogy álljon meg és javítson egy bemenetet.

Mire való a perzisztenciafájl

A fájl azért létezik, hogy a címek újraindítások között stabilak maradjanak, ami barátságosabbá teszi az újracsatlakozást és olvashatóbbá a naplókat. Történetként olvassák és történetként írják, és a kiosztási útvonal szabadon választhat más címet, ha a tipp nem illik: másik készlet, ütköző hozzárendelés vagy olyan kliens, amely a készlet megtelte után érkezett. Ezért tűnhet egy kézi szerkesztés tökéletesnek a fájlban, és nem változtat semmit a kapcsolaton. Kezelje a múltbeli döntések gyorsítótáraként, ne szabályforrásként.

Ha egy adott klienshez adott címre van szüksége, a dokumentált mechanizmus az ifconfig-push, és az ahhoz a konfigurációhoz tartozik, amely birtokolja ezt a klienst.

Ellenőrizze, hogy a megfelelő klienst választotta-e ki

A kifejezett hozzárendelést a kliens közös neve alapján keresik, így a rossz identitásra elnevezett fájlt egyszerűen soha nem olvassák. Erősítse meg, mit tekint a szerver a kliens nevének, különösen ott, ahol a username-as-common-name megváltoztatja azt a hitelesítés után. Ezután erősítse meg, hogy a fájlnév pontosan megegyezik ezzel az értékkel, a kis- és nagybetűket is beleértve.

Gondoljon az egyidejűségre, amíg itt van. Ha a duplicate-cn engedélyezett, több eszköz is ugyanazt az identitást mutathatja be, és egyetlen rögzített cím nem lehet egyedi mindegyikük számára. Döntse el, hogy a rögzített cím megéri-e az adott identitás egyidejű munkameneteinek elutasítását, mert ez a két követelmény nem teljesíthető egyszerre.

Ellenőrizze, hogy a számok illeszkednek-e a topológiához

Az argumentumok jelentése a tunel topológiájától függ, és itt okozza a legnagyobb kárt egy másolt példa. A régebbi net30 elrendezésben minden kliens négy címből álló blokkot foglal el, ezért a push egy címpárt ad. Az alhálózati topológiában a kliens egy címet és a készlet maszkját kapja, és a párforma helytelen. Olvassa ki a topológiát a futó konfigurációból, mielőtt megírja a sort.

# /etc/openvpn/ccd/partner-a   (subnet topology)
ifconfig-push 10.44.0.61 255.255.255.0

Ellenőrizze a címet minden más ellen, ami birtokolhatja: egy másik kifejezett hozzárendelés, a dinamikus készlet tartománya és minden statikus útvonal, amely rögzített gazdagépet feltételez. A készlettel átfedő cím működni fog, amíg a készlet oda nem adja valaki másnak, és ez a hiba véletlenszerűnek fog tűnni.

Ellenőrizze az eredményt egy új kapcsolaton

A meglévő munkamenet megtartja a kapott címet, ezért az egyetlen értelmes próba egy új kapcsolat. Bontsa a klienst, csatlakozzon újra, és olvassa le a címet, amelyet ténylegesen kapott, valamint azokat az útvonalakat, amelyek vele érkeztek. Ha a cím továbbra is dinamikus, a hozzárendelés nem lépett életbe, és a következő lépés a konfigurációban való keresés, nem pedig egy újabb szerkesztés a történetfájlban.

Tartsa együtt a bizonyítékokat: a kliens nevét, a megfelelő fájlt, a kiosztott címet és a készletet, ahonnan jött.

Végül, a rögzített tunelcím nem eszközhitelesítő adat. Egy helyet jelöl a címtervben, miközben a hitelesítés továbbra is a tanúsítványon és a fiókon nyugszik. A kettő összekeverése egy címütközést olyan biztonsági feltevéssé tesz, amelyet senki sem írt le.