Tres cousas teñen que coincidir antes de que un túnel de Kerio transporte tráfico: o enderezo da interface kvnet, o valor que rexistrou o cliente e o que espera a política do servidor ou o DHCP. Cando non coinciden, o túnel autentícase igualmente e sobe igualmente, e iso é exactamente o que fai confuso o fallo. A interface créase por conexión, así que un enderezo posto a man pertence a esa sesión e a nada máis. Esa é a forma do problema, e a solución é un gancho en lugar dun ficheiro de configuración. O resto é onde ler o valor e onde aplicalo.

Por que o enderezo non deixa de reverter

kvnet é un adaptador virtual que o cliente crea ao iniciar unha conexión e elimina ao terminala. Un ip link set manual sobrevive xa que logo exactamente o que dura a sesión á que se aplicou, e a seguinte conexión comeza co que asigne o cliente. Nunha máquina onde o cliente non logra aplicar o enderezo esperado, cada reconexión reintroduce a mesma discrepancia, e a regra de concesión ou de acceso rexeita de novo o dispositivo.

Ese patrón é diagnóstico por si mesmo. Un túnel que funciona unha sesión e falla na seguinte non é un problema de credenciais, porque as credenciais non cambian entre conexións.

Lea o valor do cliente, non da interface

O cliente de Linux escribe os detalles da negociación no seu rexistro de depuración, e o enderezo que pretende usar aparece alí como o último testemuño con forma de enderezo da secuencia de conexión. Compáreo co que o núcleo ten realmente, que está a un readlink de distancia: cat /sys/class/net/kvnet/address.

Se os dous difiren, o cliente coñecía o valor correcto e non logrou aplicalo, e un gancho que o aplica despois de que exista a interface pecha esa fenda. Se o rexistro non contén ningunha dirección, o problema é anterior e corresponde á versión do cliente ou ao perfil do servidor, non a un script.

Apíqueo despois de que exista a interface

Os usuarios de NetworkManager poden deixar un script no seu directorio de despachador e actuar só cando a interface VPN sobe. Un cliente xestionado por systemd require máis coidado: un drop-in que se executa ao inicio do servizo adoita activarse antes de que exista o adaptador, así que o gancho debe esperar a interface en lugar de supoñela. Fixe o enderezo entón, e se o núcleo o rexeita mentres a ligazón está arriba, báixeo, fixe o enderezo e vólvao subir. Volva ler o testemuño extraído mediante un patrón de MAC antes de pasalo a ip link, para que unha liña de rexistro inesperada non poida converterse nun argumento.

Calquera cousa que se execute como root desde o rexistro dun cliente merece unha propiedade estreita: un ficheiro propiedade de root, non escribible por outros e sen interpolación de shell máis alá do enderezo validado. Manteña a comprobación do patrón dentro do script. Non deixe que o contido do rexistro decida que comando se executa.

Verifique a concesión en lugar da ligazón

ip -4 -o addr show dev kvnet debería mostrar un enderezo no rango esperado, ip neigh show dev kvnet debería mostrar a pasarela, e un servizo detrás da VPN debería responder. Despois desconecte e volva conectar unha vez; se o enderezo volve, o gancho dispárase co evento equivocado ou non se dispara en absoluto.

Unha interface que aparece co enderezo correcto e nunca obtén unha concesión apunta ao lado do servidor. Ese é outro comprobación e normalmente outro equipo. Confirme que a conta está permitida e que o grupo aínda ten un enderezo antes de editar o gancho outra vez.

Revise o apaño despois dunha actualización

Unha compilación do cliente que fixa o enderezo correctamente deixa o seu gancho aplicando un valor obsoleto, o que é un fallo novo introducido por unha corrección. Tampouco copie nunca unha MAC doutra máquina nin dunha publicación de foro; use o valor que este cliente rexistra para esta conta, e anote a data en que o verificou.

Manteña o script o bastante curto para lelo dunha sentada. Os apaños que analizan rexistros son temporais por natureza. Os que sobreviven son os que un lector futuro pode entender sen o fío orixinal.

Artigos relacionados