Que enderezo entregará a pool na próxima reconexión?
Os enderezos da pool seguen unha orde que non é aleatoria: primeiro o enderezo lembrado, despois o libre usado hai máis tempo. Lédea antes de fixar unha regra.
Unha regra que onte coincidía deixa de coincidir hoxe porque o cliente volveu cun outro enderezo de túnel. O asignador non é aleatorio, porén, e coñecer a súa orde converte esa sorpresa nun acontecemento previsible. Prefire o enderezo que o mesmo cliente tiña antes, recorre ao libre usado hai máis tempo e esquéceo todo se non lle dás onde lembrar. As regras que presupoñen unha concesión seguen coincidindo ata o día en que, en silencio, deixan de facelo.
A orde que segue o asignador
Cunha sesión por common name, o asignador busca primeiro un enderezo que o mesmo cliente usou antes e que agora está libre. Se ese enderezo xa non está, colle o enderezo libre que leva máis tempo inactivo. Con sesións simultáneas activadas para o mesmo nome, a preferencia polo enderezo anterior non se aplica e no seu lugar úsase o primeiro enderezo libre, porque as sesións trátanse como pares separados.
| 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 |
De aí seguen dúas consecuencias de inmediato. Un cliente que se reconecta rápido adoita conservar o seu enderezo, e por iso ninguén nota o mecanismo ata que cambia. E outro dispositivo que se conecta durante esa pequena xanela pode tomar o enderezo mentres está brevemente libre, despois do cal o primeiro cliente recibe outra cousa e toda regra baseada no número vello é errónea. Ningún dos dous acontecementos produce unha liña de rexistro que pareza unha falla.
Por que unha concesión parece estable e despois se move
A estabilidade aquí é unha propiedade emerxente das reconexións que chegan antes de que ninguén máis reclame o enderezo. Non é unha promesa, e non se aplica mentres o cliente está desconectado. Prevé que o enderezo cambie en lugar de sorprenderte cando o faga. Unha pool apenas maior que o número de dispositivos fai rutineiras as colisións, porque o recurso ao enderezo usado hai máis tempo case non ten onde escoller.
A concorrencia punta é a cifra coa que hai que dimensionar, non o número de usuarios. Alguén que proba desde dous dispositivos á vez, ou un cliente que se reconecta antes de que expire a sesión anterior, ocupa dúas concesións durante un anaco. Unha pool dimensionada só para o número de persoas producirá exactamente a rotación que a xente bota a culpa ao servidor.
O ficheiro de persistencia lembra, non reserva
Un enderezo que sobrevive a un reinicio do servizo necesita un ficheiro de persistencia. Garda o nome do cliente e o enderezo ao apagar e vólveos ler ao arrancar o servizo, e por iso un reinicio planificado xa non remexe todas as regras que escribiches.
ifconfig-pool-persist /etc/openvpn/ipp.txt
server 10.8.0.0 255.255.255.0O que non fai é reter o enderezo mentres o cliente está fóra. Nese oco o asignador é libre de darlle o número a outra persoa, e o ficheiro rexistra entón unha preferencia obsoleta que a seguinte conexión non pode cumprir. Trátao como unha pista que mellora o comportamento ao reiniciar, non como enderezo estático.
Comproba a pool contra cada subrede encamiñada mentres estás no ficheiro. Un intervalo superposto entrega enderezos aos que o servidor non pode encamiñar, e o síntoma é un cliente que se conecta, recibe un enderezo e non chega a ningures.
Fixar un enderezo correctamente
Cando unha regra de cortalumes ou un rexistro DNS precisa de verdade un enderezo fixo, asígnallelo en lugar de esperalo. Unha entrada de configuración por cliente pode enviar un enderezo e unha máscara directamente, e esa entrada está indexada polo nome efectivo do cliente.
# client-config-dir entry for "laptop-acme"
ifconfig-push 10.8.0.50 255.255.255.0Mantén os enderezos fixos fóra da pool dinámica para que o asignador nunca lle dea o mesmo número a outra sesión. Despois revisa a topoloxía do túnel, porque cambia cantos enderezos da pool consume cada cliente: a antiga disposición punto a punto consume un bloque pequeno por cliente, mentres que unha disposición de subrede usa un enderezo cada un. Unha pool que parece xenerosa cunha topoloxía pode esgotarse coa outra.
Confirma o resultado no cliente en lugar de confiar na contabilidade do servidor. Cando a sesión volva, mira o enderezo da interface e a ruta enviada, porque un rexistro no servidor pode informar o enderezo solicitado mentres a interface ten outro.
O enderezo remoto é unha cuestión aparte
O enderezo da liña remota do cliente debe ser alcanzable antes de que exista ningún túnel. Poñer alí un enderezo da pool, como o propio punto final do túnel do servidor, fai que o cliente intente alcanzar o punto final a través dun túnel que aínda non construíu, e o resultado é un bucle ou un tempo de espera silencioso en lugar dun atallo.
Usa o punto final público que forneceu o operador e reserva a pool para aquilo para o que foi deseñada: enderezos dentro do túnel. Anotar o intervalo da pool, as asignacións fixas e a ruta de persistencia nun só lugar aforra á seguinte persoa tratar cada concesión como arbitraria.