Non hai tun0? Faga coincidir o IPsec descifrado en nftables con meta ipsec

Espera unha interface de túnel, búscaa e non hai nada co que coincidir no cortalumes. Iso é normal nunha pasarela baseada en políticas: o intercambio cifrado chega pola interface física, e o paquete interno descifrado que despois se reenvía tamén se observa chegando por esa mesma interface. Non hai tun0 porque nada o creou.

A petición interna segue sendo un paquete distinto coa súa propia orixe, destino e servizo, e o núcleo sabe de que asociación de seguranza saíu. Ese coñecemento é o que unha regra de cortalumes pode facer coincidir.

Dous paquetes, unha interface

Imaxine a dirección de entrada. Chega un paquete encapsulado en ESP ou UDP, o núcleo atopa a política correspondente, descífrao e entrega o paquete claro á ruta de reenvío. Unha regra que só mira o nome da interface non pode distinguir ese paquete de calquera outro tráfico que chegue polo mesmo cable.

O que o distingue é o contexto do camiño de seguranza de entrada asociado ao paquete. nftables expono como meta ipsec exists, que é certo cando o paquete chegou por un camiño de seguranza IPsec. Combineo co conxunto de clientes, o destino e o servizo, e a regra vólvese abondo específica para ser segura.

Omitir o contexto é o erro habitual, e é un erro de seguranza, non estético. Unha regra que acepta calquera cousa orixinada no conxunto de clientes acepta con igual facilidade un paquete falsificado da rede local, porque o enderezo de orixe non é proba de nada por si só. O contexto do camiño de seguranza é a forma máis barata de facer que a orixe signifique algo. Escriba a regra con el desde o principio en lugar de engadilo tras unha auditoría.

Escriba a regra de reenvío

Supoña un servizo de acceso remoto IPv4 autenticado con clientes en 10.90.0.0/24 e un destino aprobado en 203.0.113.40. Un fragmento de regra para ese fluxo ten este aspecto.

meta ipsec exists ip saddr 10.90.0.0/24 \
  ip daddr 203.0.113.40 tcp dport 443 \
  oifname "eth0" counter accept

Os enderezos e a interface son exemplos que hai que substituír. Coloque o equivalente revisado na política de reenvío antes da regra que doutro xeito rexeitaría o fluxo, e non baleire un conxunto de regras existente para instalalo; unha pasarela non é un experimento de sala limpa.

Paga a pena conservar o termo oifname. Documenta a decisión de saída e impide que a regra coincida nunha dirección que non pretendía, o que importa nunha pasarela con varias rutas a internet. Nunha máquina de probas cun só enlace ascendente o termo parece redundante, e é exactamente por iso que se elimina antes de que a máquina teña un segundo enlace.

Os permisos para o intercambio exterior son aparte. A ruta de entrada da pasarela necesita os portos IKE e ESP ou de encapsulación UDP que realmente utiliza, e eses permisos non autorizan nada sobre o paquete descifrado de dentro. Mesturar ambos é como un túnel que funciona acaba cun cortalumes que reenvía todo.

O contexto de entrada non é o de saída

A mesma familia de expresións cobre a outra dirección con rt ipsec, que describe a asociación de seguranza de saída que utilizará un paquete. Responde a outra pregunta: non de onde veu este paquete, senón se estará protexido no seu seguinte treito.

Esa distinción importa nunha pasarela que termina un túnel e á vez reenvía cara a outro. Un paquete pode chegar descifrado e aínda así ter que saír cifrado, e unha aceptación escrita só para o contexto de entrada non di nada sobre o requisito de saída. Se a política esixe esa protección, o conxunto de regras debería expresala en lugar de supor que o encamiñamento se encargará.

Manteña as dúas preguntas en regras separadas para que o lector vexa cal se aplica. Unha soa regra enxeñosa que comproba ambas é máis difícil de revisar e moito máis difícil de depurar cando unha das súas metades deixa de coincidir. Dúas regras con contadores tamén lle din que requisito está fallando, algo que unha regra combinada nunca fará.

NAT non é unha decisión do cortalumes

O tráfico cara a internet desde un conxunto de clientes privado adoita necesitar tradución de orixe para que a resposta atope o camiño de volta. Pero o tráfico seleccionado para outra política IPsec de saída debe conservar a súa exención requirida, e enmascarar cada orixe privada sen pensar na seguinte decisión de protección rompe iso.

Unha aceptación dentro dunha cadea NAT tampouco é un permiso xeral. NAT e filtrado teñen tarefas distintas, e unha cadea NAT non examina cada paquete posterior dun fluxo establecido, e é xusto por iso que confiar nela para a seguranza produce regras que parecen funcionar en probas e fallan baixo carga.

O contrario tamén é certo e sorprende a xente: unha aceptación nalgún punto dunha cadea base de filtrado non ten ningún peso fronte a un rexeitamento posterior noutra cadea aplicable. A orde e o alcance da cadea deciden o resultado, non a presenza dunha aceptación no ficheiro.

Verifique o servizo interno exacto

Probe o destino e o porto concretos que autorizou, desde un cliente real, e confirme que a resposta volve. Despois probe algo que non autorizou e comprobe que non pasa, porque unha regra demasiado ampla supera a primeira proba igual de ben ca unha correcta. Unha petición que nunca sae do cliente tampouco é un resultado do cortalumes, así que lea os contadores para ver se o paquete se avaliou sequera. Dúas probas e unha lectura de contador diranlle máis que unha tarde enteira lendo o conxunto de regras.

A referencia de nftables documenta meta ipsec, rt ipsec e as expresións específicas de dirección, e é o lugar onde comprobar a sintaxe coa súa versión instalada. E manteña o alcance explícito: isto é un exemplo IPv4, non di nada sobre IPv6 e non converte o reenvío arbitrario de portos públicos en parte do servizo VPN.