Statisk OpenVPN-IP pr. klient: ifconfig-push, ikke ipp.txt

At redigere en linje i ipp.txt føles som at reservere en adresse, og det er det ikke. Den fil, der navngives af ifconfig-pool-persist, registrerer, hvilken adresse et fælles navn havde sidst, så puljen kan give den samme tilbage, når det passer. Intet i den binder den næste forbindelse til det nummer.

Kør kontrollerne nedenfor i rækkefølge. Hver af dem bekræfter enten mekanismen eller siger, at du skal stoppe og reparere et input.

Hvad persistensfilen er til

Filen findes for at holde adresser stabile mellem genstarter, hvilket gør genforbindelser venligere og logfiler lettere at læse. Den læses som historik og skrives som historik, og tildelingsvejen står frit til at vælge en anden adresse, når hintet ikke passer: en anden pulje, en tildeling i konflikt eller en klient, der ankom efter puljen blev fyldt. Derfor kan en manuel rettelse se perfekt ud i filen og intet ændre ved forbindelsen. Behandl den som en cache over tidligere beslutninger i stedet for en kilde til politik.

Hvis du har brug for en bestemt adresse til en bestemt klient, er den dokumenterede mekanisme ifconfig-push, og den hører til i den konfiguration, der ejer den klient.

Kontroller, at den rigtige klient er valgt

En eksplicit tildeling slås op på klientens fælles navn, så en fil, der er navngivet efter den forkerte identitet, bliver simpelthen aldrig læst. Bekræft, hvad serveren anser for den klients navn, især hvor username-as-common-name ændrer det efter godkendelse. Bekræft derefter, at filnavnet svarer nøjagtigt til den værdi, inklusive store og små bogstaver.

Overvej samtidighed, mens du er her. Hvis duplicate-cn er tilladt, kan flere enheder fremvise den samme identitet, og én fast adresse kan ikke være unik for dem alle. Beslut, om den faste adresse er værd at afvise samtidige sessioner for den identitet, fordi de to krav ikke kan opfyldes på samme tid.

Kontroller, at tallene passer til topologien

Betydningen af argumenterne afhænger af tunnel-topologien, og det er her, et kopieret eksempel gør mest skade. I den ældre net30-ordning optager hver klient en blok på fire adresser, så push leverer et par adresser. I subnet-topologi modtager klienten én adresse plus puljens maske, og parformen er forkert. Læs topologien fra den kørende konfiguration, før du skriver linjen.

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

Kontroller adressen mod alt andet, der kunne eje den: en anden eksplicit tildeling, det dynamiske puljeområde og enhver statisk rute, der forudsætter en fast vært. En adresse, der overlapper puljen, vil virke, indtil puljen giver den til en anden, og den fejl vil se tilfældig ud.

Kontroller resultatet på en ny forbindelse

En eksisterende session beholder den adresse, den fik, så den eneste meningsfulde test er en ny forbindelse. Afbryd klienten, genopret forbindelsen, og læs den adresse, den faktisk modtog, sammen med de ruter, der kom med den. Hvis adressen stadig er dynamisk, blev tildelingen ikke anvendt, og næste skridt er opslaget i konfigurationen snarere end endnu en rettelse i historikfilen.

Hold beviserne sammen: klientnavnet, filen der matchede, den tildelte adresse og puljen, den kom fra.

Endelig, en fast tunneladresse er ikke en enhedslegitimationsoplysning. Den angiver et sted i adresseplanen, mens godkendelse stadig hviler på certifikatet og kontoen. At forveksle de to gør en adressekonflikt til en sikkerhedsantagelse, som ingen har skrevet ned.