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

Å redigere en linje i ipp.txt føles som å reservere en adresse, og det er det ikke. Den filen, som navngis av ifconfig-pool-persist, registrerer hvilken adresse et fellesnavn hadde sist, slik at bassenget kan gi den samme tilbake når det passer. Ingenting i den binder den neste tilkoblingen til det nummeret.

Kjør kontrollene nedenfor i rekkefølge. Hver av dem bekrefter enten mekanismen eller sier at du skal stoppe og reparere en inngang.

Hva persistensfilen er til

Filen finnes for å holde adresser stabile mellom omstarter, noe som gjør gjentilkoblinger vennligere og loggene lettere å lese. Den leses som historikk og skrives som historikk, og tildelingsveien står fritt til å velge en annen adresse når hintet ikke passer: et annet basseng, en tildeling i konflikt eller en klient som kom etter at bassenget ble fylt. Derfor kan en manuell endring se perfekt ut i filen og ikke endre noe ved tilkoblingen. Behandle den som en hurtigbuffer over tidligere beslutninger, ikke som en kilde til policy.

Hvis du trenger en bestemt adresse for en bestemt klient, er den dokumenterte mekanismen ifconfig-push, og den hører til i konfigurasjonen som eier den klienten.

Kontroller at riktig klient er valgt

En eksplisitt tildeling slås opp etter klientens fellesnavn, så en fil som er navngitt etter feil identitet, blir rett og slett aldri lest. Bekreft hva serveren anser som navnet på den klienten, særlig der username-as-common-name endrer det etter autentisering. Bekreft deretter at filnavnet samsvarer nøyaktig med den verdien, inkludert store og små bokstaver.

Vurder samtidighet mens du er her. Hvis duplicate-cn er tillatt, kan flere enheter presentere samme identitet, og én fast adresse kan ikke være unik for alle. Bestem om den faste adressen er verdt å avvise samtidige økter for den identiteten, fordi disse to kravene ikke kan oppfylles samtidig.

Kontroller at tallene passer til topologien

Betydningen av argumentene avhenger av tunnel-topologien, og det er her et kopiert eksempel gjør mest skade. I den eldre net30-ordningen opptar hver klient en blokk på fire adresser, så push leverer et par adresser. I subnet-topologi mottar klienten én adresse pluss bassengets maske, og parformen er feil. Les topologien fra den kjørende konfigurasjonen før du skriver linjen.

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

Kontroller adressen mot alt annet som kan eie den: en annen eksplisitt tildeling, området for det dynamiske bassenget og enhver statisk rute som forutsetter en fast vert. En adresse som overlapper bassenget, vil virke til bassenget gir den til noen andre, og den feilen vil se tilfeldig ut.

Kontroller resultatet på en ny tilkobling

En eksisterende økt beholder adressen den fikk, så den eneste meningsfulle testen er en ny tilkobling. Koble fra klienten, koble til igjen, og les adressen den faktisk mottok sammen med rutene som kom med den. Hvis adressen fortsatt er dynamisk, ble tildelingen ikke brukt, og neste steg er oppslaget i konfigurasjonen snarere enn nok en endring i historikkfilen.

Hold bevisene sammen: klientnavnet, filen som samsvarte, den tildelte adressen og bassenget den kom fra.

Til slutt, en fast tunneladresse er ikke en enhetslegitimasjon. Den angir et sted i adresseplanen, mens autentisering fortsatt hviler på sertifikatet og kontoen. Å forveksle de to gjør en adressekonflikt til en sikkerhetsantagelse som ingen har skrevet ned.