Eu tentei encontrar algumas respostas sobre este e outros sites tentando descobrir o problema, mas minhas tentativas falharam. A regra é muito simples: quero estabelecer meu túnel Ipsec quando meu Yubikey estiver conectado.
/etc/udev/rules.d/local.rules Em que o script é como:
SUBSYSTEM=="input", ACTION=="add", ENV{ID_MODEL}=="Yubikey_4_OTP+U2F+CCID" , RUN+="/usr/local/bin/Yubikey.sh"
Em seguida, o script /usr/local/bin/Yubikey.sh contém:
#!/bin/sh
ipsec restart
if (ipsec status | grep none);then
ipsec up connection
fi
Isso invoca o script quando qualquer dispositivo de entrada é conectado e, em seguida, o script deve reiniciar o ipsec e iniciar o encapsulamento se não houver um encapsulamento iniciado anteriormente. No entanto, o túnel não inicia quando obtenho o seguinte erro quando executo o comando ipsec status :
connecting to 'unix:///var/run/charon.ctl' failed: Connection refused
failed to connect to stroke socket 'unix"//var/run/charon.ctl'
Então, depois de pesquisar mais, descobri que o problema no script /usr/local/bin/Yubikey.sh que chama ipsec como um serviço causou falha no soquete de traço charon.ctl .
Em vez disso, tive que mudá-lo para:
#!/bin/sh
service strongswan restart
Então, eu tive que usar o strongswan em vez do ipsec como nas distribuições recentes, o comando ipsec foi renomeado para strongswan .
Por padrão, somente o root tem permissão para acessar esse socket (e outros criados pelo strongSwan). Existem opções para alterar isso . Por exemplo, com charon.group em strongswan.conf usuários que são membros do grupo configurado também podem acessar o soquete. Também pode haver algum módulo de segurança no nível do kernel (por exemplo, AppArmor) em seu sistema que possa impedir o acesso ao soquete (verifique o log do sistema em busca de entradas e talvez adapte as políticas de acordo).
Em vez de usar o ipsec / starter / stroke obsoleto, convém mudar para VICI / swanctl .