IP estàtica d'OpenVPN per client: ifconfig-push, no ipp.txt

Editar una línia a ipp.txt sembla reservar una adreça, i no ho és. Aquest fitxer, anomenat per ifconfig-pool-persist, registra quina adreça tenia un nom comú l'última vegada perquè el pool pugui tornar la mateixa quan convingui. Res no hi lliga la connexió següent a aquest número.

Feu les comprovacions següents en ordre. Cadascuna confirma el mecanisme o us diu que us atureu i repareu una entrada.

Per a què serveix el fitxer de persistència

El fitxer existeix per mantenir les adreces estables entre reinicis, cosa que fa les reconnexions més amables i els registres més fàcils de llegir. Es llegeix com a història i s'escriu com a història, i el camí d'assignació queda lliure per triar una altra adreça quan la pista no encaixa: un pool diferent, una assignació en conflicte o un client que va arribar després que el pool s'omplís. Per això una edició manual pot semblar perfecta al fitxer i no canviar res a la connexió. Tracteu-lo com una memòria cau de decisions passades i no com una font de política.

Si necessiteu una adreça concreta per a un client concret, el mecanisme documentat és ifconfig-push, i pertany a la configuració que posseeix aquest client.

Comproveu que s'hagi seleccionat el client correcte

L'assignació explícita es busca pel nom comú del client, de manera que un fitxer anomenat per a la identitat equivocada simplement no es llegeix mai. Confirmeu què considera el servidor que és el nom d'aquest client, sobretot on username-as-common-name el canvia després de l'autenticació. Després confirmeu que el nom del fitxer coincideix exactament amb aquest valor, majúscules i minúscules incloses.

Penseu en la concurrència mentre sou aquí. Si duplicate-cn està permès, diversos dispositius poden presentar la mateixa identitat, i una adreça fixa no pot ser única per a tots ells. Decidiu si l'adreça fixa val la pena de rebutjar sessions concurrents per a aquesta identitat, perquè aquests dos requisits no es poden satisfer alhora.

Comproveu que els números coincideixin amb la topologia

El significat dels arguments depèn de la topologia del túnel, i és aquí on un exemple copiat fa més mal. En la disposició net30 més antiga cada client ocupa un bloc de quatre adreces, així que el push subministra un parell d'adreces. En la topologia de subxarxa el client rep una adreça més la màscara del pool, i la forma de parell és incorrecta. Llegiu la topologia de la configuració en execució abans d'escriure la línia.

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

Comproveu l'adreça contra tota la resta que podria posseir-la: una altra assignació explícita, el rang del pool dinàmic i qualsevol ruta estàtica que pressuposi un amfitrió fix. Una adreça que se superposi al pool funcionarà fins que el pool la doni a algú altre, i aquesta fallada semblarà aleatòria.

Comproveu el resultat en una connexió nova

Una sessió existent conserva l'adreça que se li va donar, així que l'única prova significativa és una connexió nova. Desconnecteu el client, torneu-lo a connectar i llegiu l'adreça que realment ha rebut juntament amb les rutes que hi han arribat. Si l'adreça encara és dinàmica, l'assignació no s'ha aplicat, i el següent pas és la consulta de la configuració i no una altra edició del fitxer d'història.

Manteniu les proves juntes: el nom del client, el fitxer que va coincidir, l'adreça assignada i el pool d'on va sortir.

Finalment, una adreça de túnel fixa no és una credencial del dispositiu. Identifica un lloc en el pla d'adreces, mentre que l'autenticació encara descansa en el certificat i el compte. Confondre les dues coses converteix un conflicte d'adreces en una suposició de seguretat que ningú no ha escrit.