Staatiline OpenVPN IP kliendi kohta: ifconfig-push, mitte ipp.txt

Rea muutmine failis ipp.txt tundub aadressi broneerimisena, kuid seda see pole. See fail, mille nimi tuleb ifconfig-pool-persist-ist, registreerib, milline aadress oli ühisel nimel viimati, et bassein saaks sama tagasi anda, kui see sobib. Miski selles ei seo järgmist ühendust selle numbriga.

Tehke allolevad kontrollid järjekorras. Igaüks neist kas kinnitab mehhanismi või ütleb teil peatuda ja sisend parandada.

Milleks püsivusfail on

Fail on olemas selleks, et hoida aadressid taaskäivituste vahel stabiilsed, mis teeb taasühendused sõbralikumaks ja logid loetavamaks. Seda loetakse ajaloona ja kirjutatakse ajaloona ning jaotusrada jääb vabaks valida teine aadress, kui vihje ei sobi: teine bassein, vastuoluline määramine või klient, kes saabus pärast basseini täitumist. Seetõttu võib käsitsi tehtud muudatus failis täiuslik välja näha ja ühenduses mitte midagi muuta. Käsitlege seda varasemate otsuste vahemäluna, mitte poliitika allikana.

Kui vajate konkreetsele kliendile konkreetset aadressi, on dokumenteeritud mehhanism ifconfig-push ja see kuulub konfiguratsiooni, mis seda klienti omab.

Kontrollige, et õige klient on valitud

Otsest määramist otsitakse kliendi ühise nime järgi, nii et vale identiteedi jaoks nimetatud faili lihtsalt ei loeta kunagi. Kinnitage, mida server peab selle kliendi nimeks, eriti seal, kus username-as-common-name muudab seda pärast autentimist. Seejärel kinnitage, et faili nimi vastab täpselt sellele väärtusele, sealhulgas suurtähtede ja väiketähtede eristus.

Mõelge paralleelsusele, kuni olete siin. Kui duplicate-cn on lubatud, võivad mitmed seadmed esitada sama identiteedi ja üks fikseeritud aadress ei saa olla kõigi jaoks ainulaadne. Otsustage, kas fikseeritud aadress on väärt keelduma selle identiteedi samaaegsetest sessioonidest, sest neid kahte nõuet ei saa korraga täita.

Kontrollige, et numbrid vastavad topoloogiale

Argumentide tähendus sõltub tunnelitopoloogiast ja just siin teeb kopeeritud näide kõige rohkem kahju. Vanemas net30 paigutuses hõivab iga klient nelja aadressi ploki, seega push annab aadressipaari. Alamsvõrgu topoloogias saab klient ühe aadressi pluss basseini maski ning paarivorm on vale. Lugege topoloogia töötavast konfiguratsioonist enne rea kirjutamist.

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

Kontrollige aadressi kõige muu vastu, mis võiks seda omada: teine otsene määramine, dünaamilise basseini vahemik ja iga staatiline marsruut, mis eeldab fikseeritud hosti. Basseini kattuv aadress töötab seni, kuni bassein annab selle kellelegi teisele, ja see tõrge näib juhuslik.

Kontrollige tulemust uuel ühendusel

Olemasolev sessioon hoiab talle antud aadressi, seega on ainus mõttekas test uus ühendus. Ühendage klient lahti, ühendage uuesti ja lugege aadress, mille see tegelikult sai, koos sellega saabunud marsruutidega. Kui aadress on endiselt dünaamiline, ei rakendatud määramist, ja järgmine samm on konfiguratsiooni otsing, mitte veel üks ajaloo faili muudatus.

Hoidke tõendid koos: kliendi nimi, sobiv fail, määratud aadress ja bassein, kust see tuli.

Lõpuks, fikseeritud tunneliaadress ei ole seadme mandaat. See tähistab kohta aadressiplaanis, samal ajal kui autentimine toetub endiselt sertifikaadile ja kontole. Kahe segiajamine muudab aadressikonflikti turvaeelduseks, mida keegi ei kirjutanud.