Statisk OpenVPN-IP per klient: ifconfig-push, ikkje ipp.txt

Å redigere ei linje i ipp.txt kjennest som å reservere ei adresse, og det er det ikkje. Den fila, som blir namngitt av ifconfig-pool-persist, registrerer kva adresse eit fellesnamn hadde sist, slik at bassenget kan gi den same tilbake når det passar. Ingenting i ho bind den neste tilkoplinga til det nummeret.

Køyr kontrollane nedanfor i rekkjefølgje. Kvar av dei stadfester anten mekanismen eller seier at du skal stoppe og reparere ei inngang.

Kva persistensfila er til

Fila finst for å halde adresser stabile mellom omstartar, noko som gjer gjenoppkoplingar venlegare og loggane lettare å lese. Ho blir lesen som historikk og skriven som historikk, og tildelingsvegen står fritt til å velje ei anna adresse når hintet ikkje passar: eit anna basseng, ei tildeling i konflikt eller ein klient som kom etter at bassenget vart fylt. Difor kan ei manuell endring sjå perfekt ut i fila og ikkje endre noko ved tilkoplinga. Behandle ho som ein hurtigbuffer over tidlegare avgjerder, ikkje som ei kjelde til policy.

Viss du treng ei bestemd adresse for ein bestemd klient, er den dokumenterte mekanismen ifconfig-push, og han høyrer til i konfigurasjonen som eig den klienten.

Kontroller at rett klient er vald

Ei eksplisitt tildeling blir slått opp etter fellesnamnet til klienten, så ei fil som er namngitt etter feil identitet, blir rett og slett aldri lesen. Stadfest kva tenaren reknar som namnet på den klienten, særleg der username-as-common-name endrar det etter autentisering. Stadfest deretter at filnamnet svarar nøyaktig til den verdien, inkludert store og små bokstavar.

Vurder samtidigheit medan du er her. Viss duplicate-cn er tillate, kan fleire einingar presentere same identitet, og éi fast adresse kan ikkje vere unik for alle. Avgjer om den faste adressa er verdt å avvise samtidige økter for den identiteten, fordi desse to krava ikkje kan oppfyllast samtidig.

Kontroller at tala passar til topologien

Tydinga av argumenta avheng av tunnel-topologien, og det er her eit kopiert døme gjer mest skade. I den eldre net30-ordninga opptar kvar klient ein blokk på fire adresser, så push leverer eit par adresser. I subnet-topologi får klienten éi adresse pluss maska til bassenget, og parforma er feil. Les topologien frå den køyrande konfigurasjonen før du skriv linja.

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

Kontroller adressa mot alt anna som kan eige ho: ei anna eksplisitt tildeling, området for det dynamiske bassenget og kvar statisk rute som føreset ein fast vert. Ei adresse som overlappar bassenget, vil verke til bassenget gir ho til nokon andre, og den feilen vil sjå tilfeldig ut.

Kontroller resultatet på ei ny tilkopling

Ei eksisterande økt held adressa ho fekk, så den einaste meiningsfulle testen er ei ny tilkopling. Kople frå klienten, kople til att, og les adressa han faktisk fekk saman med rutene som kom med ho. Viss adressa framleis er dynamisk, vart tildelinga ikkje brukt, og neste steg er oppslaget i konfigurasjonen snarare enn endå ei endring i historikkfila.

Hald prova saman: klientnamnet, fila som svara, den tildelte adressa og bassenget ho kom frå.

Til slutt, ei fast tunneladresse er ikkje ein einingslegitimasjon. Ho angir ein stad i adresseplanen, medan autentisering framleis kviler på sertifikatet og kontoen. Å forveksle dei to gjer ein adressekonflikt til ei tryggingsføresetnad som ingen har skrive ned.