Quina adreça lliurarà el pool a la propera reconnexió?
Les adreces del pool segueixen un ordre que no és aleatori: primer l’adreça recordada, després la lliure usada menys recentment. Llegeix-lo abans de fixar una regla.
Una regla que ahir coincidia deixa de coincidir avui perquè el client ha tornat amb una altra adreça de túnel. L’assignador, però, no és aleatori, i conèixer el seu ordre converteix aquesta sorpresa en un esdeveniment previsible. Prefereix l’adreça que el mateix client tenia abans, recorre a la lliure usada menys recentment i ho oblida tot si no li dones on recordar. Les regles que pressuposen una concessió continuen coincidint fins al dia que, en silenci, deixen de fer-ho.
L’ordre que segueix l’assignador
Amb una sessió per common name, l’assignador busca primer una adreça que el mateix client va fer servir abans i que ara és lliure. Si aquesta adreça ja no hi és, agafa l’adreça lliure que porta més temps inactiva. Amb sessions simultànies activades per al mateix nom, la preferència per l’adreça anterior no s’aplica i en el seu lloc es fa servir la primera adreça lliure, perquè les sessions es tracten com a parells separats.
| Situation | Address chosen | Practical effect |
|---|---|---|
| Reconnect, old address still free | The remembered address | Rules appear stable for days |
| Old address taken by another client | Least recently used free address | A working rule silently stops matching |
| Concurrent sessions, same name | First free address, per session | One identity can hold several leases |
D’aquí se segueixen dues conseqüències de seguida. Un client que es reconnecta de pressa sol conservar l’adreça, i per això ningú no nota el mecanisme fins que canvia. I un altre dispositiu que es connecta durant aquesta petita finestra pot prendre l’adreça mentre és breument lliure, i després el primer client rep una altra cosa i tota regla basada en el número antic és errònia. Cap dels dos esdeveniments no produeix una línia de registre que sembli una fallada.
Per què una concessió sembla estable i després es mou
L’estabilitat aquí és una propietat emergent de reconnexions que arriben abans que ningú altre reclami l’adreça. No és una promesa, i no s’aplica mentre el client està desconnectat. Preveu que l’adreça canviï en lloc de quedar-te sorprès quan ho faci. Un pool amb prou feines més gran que el nombre de dispositius fa rutinàries les col·lisions, perquè el recurs a l’adreça usada menys recentment gairebé no té on triar.
La concurrència punta és la xifra amb què s’ha de dimensionar, no el nombre d’usuaris. Algú que prova des de dos dispositius alhora, o un client que es reconnecta abans que caduqui la sessió anterior, ocupa dues concessions durant una estona. Un pool dimensionat només per al nombre de persones produirà exactament la rotació que la gent culpa al servidor.
El fitxer de persistència recorda, no reserva
Una adreça que sobreviu a un reinici del servei necessita un fitxer de persistència. Desa el nom del client i l’adreça en aturar-se i els torna a llegir en arrencar el servei, i per això un reinici planificat ja no remena totes les regles que vas escriure.
ifconfig-pool-persist /etc/openvpn/ipp.txt
server 10.8.0.0 255.255.255.0El que no fa és retenir l’adreça mentre el client és fora. En aquest buit l’assignador és lliure de donar el número a algú altre, i el fitxer registra aleshores una preferència obsoleta que la connexió següent no pot complir. Tracta’l com un indici que millora el comportament en reiniciar, no com a adreçament estàtic.
Comprova el pool contra cada subxarxa encaminada mentre ets al fitxer. Un interval superposat lliura adreces a les quals el servidor no pot encaminar, i el símptoma és un client que es connecta, rep una adreça i no arriba enlloc.
Fixar una adreça correctament
Quan una regla de tallafocs o un registre DNS necessita de debò una adreça fixa, assigna-la en lloc d’esperar-la. Una entrada de configuració per client pot enviar una adreça i una màscara directament, i aquesta entrada s’indexa pel nom efectiu del client.
# client-config-dir entry for "laptop-acme"
ifconfig-push 10.8.0.50 255.255.255.0Mantén les adreces fixes fora del pool dinàmic perquè l’assignador no lliuri mai el mateix número a una altra sessió. Després revisa la topologia del túnel, perquè canvia quantes adreces del pool consumeix cada client: l’antiga disposició punt a punt consumeix un bloc petit per client, mentre que una disposició de subxarxa fa servir una adreça cadascú. Un pool que sembla generós amb una topologia es pot esgotar amb l’altra.
Confirma el resultat al client en lloc de confiar en la comptabilitat del servidor. Quan la sessió torni, mira l’adreça de la interfície i la ruta enviada, perquè un registre al servidor pot informar de l’adreça sol·licitada mentre la interfície en té una altra.
L’adreça remota és una qüestió a part
L’adreça de la línia remota del client ha de ser abastable abans que existeixi cap túnel. Posar-hi una adreça del pool, com el propi punt final del túnel del servidor, fa que el client intenti arribar al punt final a través d’un túnel que encara no ha construït, i el resultat és un bucle o un temps d’espera silenciós en lloc d’una drecera.
Fes servir el punt final públic que va proporcionar l’operador i reserva el pool per a allò per a què va ser dissenyat: adreces dins del túnel. Anotar l’interval del pool, les assignacions fixes i el camí de persistència en un sol lloc estalvia a la persona següent tractar cada concessió com a arbitrària.