NEW de conntrack nun paquete ACK: que non demostra
Un ACK etiquetado NEW significa que o rastrexador non tiña estado coincidente, non que a VPN abrise unha sesión. Le o hook, a tupla e a xanela de captura.
No rexistro da devasa hai unha liña que non esperabas: un paquete ACK, estado de conntrack NEW, un enderezo de orixe que non é o teu, porto de destino aberto. A tentación é lelo como unha conexión entrante nova que ninguén autorizou. O que di realmente a liña é máis estreito: cando ese paquete chegou a este hook, o rastrexador non tiña estado coincidente, e o paquete levaba un ACK. Son dous feitos sobre dúas cousas distintas, e ningún dos dous é unha transcrición completa dunha aperta de mans. Esta é a orde que sigo antes de sacar unha conclusión.
Comeza polo paquete, non polo veredicto
Separa as observacións antes de interpretalas. As bandeiras TCP describen este paquete, o estado do rastrexador describe o que sabía nese hook, e a túa captura describe só a xanela que rexistraches.
Confundir esas tres cousas é como un ACK se converte en «o provedor deixou entrar a alguén».
Que significa NEW realmente no hook
A coincidencia de conntrack de iptables documenta NEW como un paquete que inicia unha conexión, ou un asociado a unha conexión que aínda non viu tráfico nos dous sentidos. ESTABLISHED significa que o rastrexador viu paquetes nos dous sentidos. Ningunha das dúas definicións di que o paquete fose un SYN, nin que chegase sen historial.
Un rastrexador que comeza a observar un fluxo a medio camiño clasifica o seguinte paquete segundo o que sabe, que pode ser nada. Iso fala da memoria do rastrexador, non da intención do host remoto.
O seguimento laxo explica a maioría das sorpresas con ACK
O núcleo documenta nf_conntrack_tcp_loose, que permite ao rastrexador coller conexións TCP das que non viu o inicio. Co axuste no seu valor predeterminado, un ACK de medio fluxo pode adoptarse como fluxo establecido. Desactívao e o mesmo paquete será máis probablemente clasificado como INVALID en lugar de NEW. Ambos resultados describen as regras do rastrexador, non o historial da aplicación.
Así que revisa ese axuste antes de construír unha teoría sobre a etiqueta.
Descarta as causas aburridas nesta orde
A maioría dos eventos NEW sobre ACK que perseguín remataron nunha destas, e todas son baratas de comprobar:
- Baleirouse a táboa de conntrack, ou o rastrexador reiniciouse.
- O host reiniciouse, ou o fluxo pasou a outro namespace ou dispositivo.
- O encamiñamento asimétrico enviou o SYN por un camiño que non estás capturando.
- NAT reescribiu a tupla, así que a entrada xa non coincide co que liches.
- A captura comezou tarde e nunca viu o comezo.
Cada unha delas quita os paquetes anteriores da vista do rastrexador e deixa intactos os posteriores. Un reinicio ou un baleirado da táboa é o máis doado de confirmar co uptime e os rexistros. O encamiñamento asimétrico vese como unha captura unidireccional. NAT é o astuto, porque a tupla que gardou o rastrexador non é a tupla impresa no rexistro.
Anota cales destas descartaches, e como, antes de seguir.
Le a tupla, a interface e o hook
Unha entrada de conntrack indexase por enderezos, portos e protocolo, así que calquera tradución cambia que entrada coincide. Anota tamén a interface e o hook, porque un paquete visto na interface equivocada ou tras unha cadea distinta diche que o camiño non é o do diagrama. Cando o evento implica unha VPN, decide se miras o paquete interno ou o portador externo. Despois compara co que a pasarela rexistrou para a mesma tupla de cinco partes.
Dúas vistas dun mesmo fluxo que non coinciden son máis informativas que calquera das dúas por separado.
Cando paga a pena escalar
Escala cando poidas mostrar un servizo que é accesible e non debería sero, co fluxo, a política que o permitiu e probas de ambos extremos. Non informes dun defecto do provedor baseándote nunha etiqueta de estado ou nunha captura parcial, porque ese informe pecharase coa explicación que acabas de ler. Se o servizo está realmente exposto, o dono desa fronteira é a persoa axeitada para arranxalo, e unha asignación de portos delegada ou un oínte non desexado é unha causa máis probable que un erro.
Despois pecha a fenda de visibilidade que permitiu que un só paquete parecese unha sesión enteira.