Que compoñente posúe realmente un límite de rutas de OpenVPN?
Un límite de rutas pode pertencer ao motor de OpenVPN, ao complemento de NetworkManager ou ao servidor. Nomee o propietario antes de editar un perfil ou subir un número.
Un perfil con duascentas rutas funciona nunha máquina e instala corenta noutra. O motor, a integración que o arranca e o servidor que o alimenta teñen voz, e cada un pode deter a lista nun punto distinto. Ler o fallo como un único límite lévate ao ficheiro equivocado. O mecanismo ten tres etapas, e a etapa que se detivo deixa probas visibles cando sabes que buscar.
Tres etapas, tres límites distintos
Primeiro o motor analiza a opción e decide se esta versión a entende. Despois a integración instala o que o motor informa, e o seu propio código pode limitar ou remodelar a lista. Por último o servidor decide cantas rutas enviará a unha identidade concreta, antes de que ningunha etapa do cliente vexa nada. Tres etapas, tres teitos, e só un deles é o número do perfil.
Subir un teito non fai nada polos demais. Unha ruta enviada e rexeitada pode ser unha decisión de política no servidor, un solapamento que o cliente resolveu, ou un límite do instalador que descartou o exceso. Cada un deses casos ten unha solución distinta.
Separa os tres antes de medir nada. Un erro do analizador nomea un testemuño, un límite do instalador deixa unha táboa de rutas curta, e unha decisión de política non deixa absolutamente nada. As probas dinche que etapa inspeccionar primeiro.
| Stage | Who decides | What you can see |
|---|---|---|
| Parse | Client engine | An error naming the option |
| Install | Activation owner | A route count below the pushed count |
| Offer | Server policy | A route absent from the pushed list |
O analizador fala primeiro
Unha opción descoñecida falla ruidosamente e cedo, e o texto do erro nomea o testemuño. Esa é a etapa máis fácil de identificar: compara a mensaxe exacta coa versión instalada do motor, porque unha opción engadida nunha versión é descoñecida na anterior. Un perfil copiado dun despregamento máis novo é a causa habitual dese desaxuste. O analizador nunca ignora en silencio unha directiva que non recoñece.
Unha opción aceptada non di nada sobre o resultado. A análise ten éxito, e a lista aínda pode quedar recortada polo instalador ou non ser ofrecida nunca polo servidor. Trata unha análise limpa como permiso para continuar, non como proba.
Anota a cadea de versión do binario que realmente se executou, non da idea que ten o xestor de paquetes do que está instalado. Esas dúas discrepan máis a miúdo do que se espera.
O instalador ten o seu propio teito
O compoñente que posúe a activación pode ser un complemento de NetworkManager en lugar do binario do motor, e pode impoñer o seu propio límite antes de que exista calquera túnel. O seu editor pode mostrar un campo que o motor en marcha nunca le, ou ler un campo que o editor non mostra. Ambas as situacións parecen un fallo do cliente desde fóra. Ningunha se corrixe editando o perfil.
Conta o que chegou en lugar do que se configurou. A orde ip route show dev tun0 lista as rutas instaladas, e comparar ese reconto coa lista enviada separa unha ruta descartada dunha que nunca se enviou. Un reconto que coincide co envío devolve a sospeita ao servidor.
Unha capa de shell arredor do binario do motor para forzar un número maior difumina as actualizacións e converte a reversión nunha adiviñanza. Tamén oculta o límite real a quen lea a configuración despois.
O servidor decide que che ofreceron
A política por cliente pode reducir a lista antes de que se transmita. Un ficheiro específico do cliente pode engadir rutas para unha identidade, ou unha política de grupo pode omitilas, e o cliente non pode distinguir unha ruta filtrada dunha que nunca se definiu. Esa ambigüidade é a razón pola que importa o rexistro do servidor. Pide a lista efectiva de envío para esa identidade, non o modelo.
Compara o rexistro do servidor coa lista recibida. A fenda entre ambos é a capa de política, e adoita ser menor do que o perfil suxire.
Cando o deseño o permite, resume as redes contiguas e borra as entradas obsoletas. Menos rutas e máis grandes resolven máis casos que un teito máis alto.
Cambia o número no lugar correcto
Usa o axuste documentado do compoñente que realmente posúe o límite. Se o campo falta no complemento, comproba se o complemento é anterior á función ou se outro fondo posúe as rutas. Despois documenta as versións do motor, do complemento e do servidor xunto ao valor que escolliches. A seguinte actualización reabre a pregunta, e a nota é o que permite respondela.
Proba de novo tras calquera actualización de calquera dos tres. Un límite subido no lugar correcto móvese igualmente cando cambia o compoñente que o aplica. O rexistro de versións é o único que fai previsible ese movemento.