Quatro respostas do empregador decidem se um Pi pode entrar na VPN de trabalho: que protocolo de gateway fala, que sistemas operativos e arquiteturas suporta, como a autenticação deve acontecer e se é permitido um cliente diferente do oficial. Um URL de portal e a palavra Linux não resolvem nenhuma delas. Pergunte antes de transferir seja o que for, porque as respostas mudam que pacote instala e se uma configuração sem ecrã é sequer viável.

Anote as quatro respostas. O resto deste texto é o que cada uma muda.

O protocolo do gateway decide o cliente

O gateway fala um ou mais protocolos, e o cliente tem de implementar aquele que a sua organização executa realmente. O OpenConnect é uma implementação independente que começou com compatibilidade com o Cisco AnyConnect e agora cobre várias outras gateways empresariais; não é o cliente de marca do fornecedor, e a compatibilidade de protocolo não garante suporte a cada função da gateway, verificação de postura ou política de dispositivo. Confirme o protocolo com a equipa de rede em vez de o inferir do URL do portal. Depois confirme que o empregador aceita este cliente para esta implementação.

As provas de compatibilidade têm de vir da documentação do empregador ou de um colega que o tenha feito no mesmo modelo, não da existência de um pacote num repositório.

A arquitetura não é um detalhe

Anote a versão do sistema operativo e a arquitetura de espaço de utilizador do Pi, a versão do cliente que pretende usar e de onde vem esse pacote. Um instalador x86 não se torna adequado a outra arquitetura porque o nome do ficheiro mudou, e um cliente do fornecedor que só distribui compilações x86 não consegue de todo correr no Pi. Este único facto pode resolver toda a questão antes de a autenticação ser sequer discutida. Verifique a manutenção da origem do pacote em vez de instalar um binário perdido de um fio de fórum.

Um espaço de utilizador de 64 bits sobre um kernel de 64 bits é o caso simples; um espaço de utilizador de 32 bits numa placa de 64 bits é onde as pessoas instalam o pacote errado. O dpkg --print-architecture e o uname -m respondem às duas metades numa linha cada.

A autenticação decide o fluxo de trabalho

Palavras-passe, MFA e início de sessão através do navegador impõem cada um o seu próprio fluxo de trabalho. Um certificado guardado num token de hardware pode exigir um controlador que o Pi não tem, enquanto um fluxo SSO pode abrir uma janela de navegador que uma sessão sem ecrã não consegue mostrar. Algumas gateways oferecem um caminho por código de dispositivo ou cópia manual precisamente para esse caso, e outras não. Pergunte que método a organização suporta para um anfitrião Linux sem ecrã, e depois teste-o antes de depender dele.

A integração do frontend é uma escolha separada da autenticação. Um plugin do NetworkManager pode preparar uma ligação e guardar os seus segredos, mas não pode tornar compatível um método de autenticação não suportado. Mantenha estas duas perguntas separadas.

Mantenha intacta a fronteira do empregador

Se a organização exige o seu cliente oficial, um dispositivo gerido ou uma distribuição suportada, siga esse requisito ou peça uma alternativa aprovada. Desativar verificações de certificados, imitar resultados de postura ou desligar controlos de ponto final para que outro cliente pareça aceite transforma um problema de compatibilidade numa violação de política. Mantenha palavras-passe, cookies de sessão e chaves privadas fora do histórico da shell e das transcrições de conversa. Um desafio-resposta funcional não é permissão para publicar o material da sessão.

Após uma inscrição aprovada, confirme o DNS privado, os recursos previstos, um recurso negado e a reconexão, tudo a partir do próprio Pi. Um túnel com sessão iniciada ainda pode encaminhar mal ou não ter autorização.

O resultado é um acordo sustentável com um responsável nomeado: que cliente, que versão, que caminho de inscrição. Isso é melhor do que instalar o cliente próximo do fornecedor e esperar que os restantes requisitos se revelem opcionais.

Artigos relacionados