Pasarela ou cliente reenviado? Ler o enderezo de orixe

O servidor web rexistra un enderezo, e todos asumen que pertence ao proceso da propia pasarela. Pode pertencer a un cliente reenviado cuxo enderezo privado desapareceu no paso de tradución. O destino ve a orixe de rede visible e nada máis. É unha afirmación de fronteira, non a pretensión de que a orixe nunca poida establecerse.

O que ve realmente o destino

Tome un cliente en 10.20.0.7, unha pasarela cuxo enderezo exterior é 198.51.100.10 e un destino en internet. Se a pasarela traduce a orixe do cliente, o socket do destino rexistra 198.51.100.10. O enderezo privado desaparece do paquete, e o destino non pode volvelo ler desa cabeceira. Eses números son ilustrativos, non unha captura da súa rede.

A observación segue sendo útil: identifica a orixe de rede que o destino debe permitir ou bloquear. Simplemente non identifica a persoa nin o proceso que hai detrás. Para o operador do destino, esa distinción decide se un bloqueo é unha decisión de rede ou unha decisión de conta.

O estado de tradución non é visible para o destino

A pasarela mantén a correspondencia entre a conexión traducida e o cliente orixinal, e ese estado é exactamente o que lle falta ao destino. descrición tradicional do NAT separa o rexistro de tradución das cabeceiras visibles despois. Ler un lado non lle dá o outro.

Deseños distintos producen probas distintas. O tráfico encamiñado con enderezos de orixe preservados mostra o enderezo real do cliente, mentres que un proxy de aplicación remata a conexión e crea unha nova. Unha ruta con orixe preservada tamén require que o enderezo do cliente sexa encamiñable de volta desde o destino, algo que non todos os despregamentos ofrecen. Pregunte que deseño está despregado antes de interpretar unha liña de rexistro.

conntrack -L -s 198.51.100.10
tcpdump -ni eth0 host 198.51.100.10

O TTL e as pegadas son pistas, non probas

O TTL en IPv4 depende do valor inicial elixido polo emisor e do número de saltos que cruzou o paquete. Sen ambos os feitos, un valor non pode demostrar que se produciu un salto de VPN. Un salto encamiñado adicional coñecido tampouco distingue un encamiñador de LAN, unha ruta de túnel ou outra disposición de reenvío. Trate unha diferenza de TTL como unha pregunta, non como unha conclusión.

Outros sinais compórtanse igual. Unha cabeceira User-Agent pode establecela a aplicación, e a similitude de tempos pode reflectir infraestrutura compartida en lugar dunha persoa compartida. Varios usuarios poden compartir unha saída, e un usuario pode cambiar de ruta entre sesións. Recollidas xuntas, varias sinais febles poden xustificar unha ollada máis atenta aos rexistros dunha pasarela, pero non se converten en probas sólidas por acumulación.

Autorice por identidade, non por enderezo

Se o destino debe separar a administración da pasarela da actividade de usuarios remotos, dea a eses roles identidades autenticadas separadas e operacións permitidas. Unha orixe pública compartida aínda pode servir como restrición de rede, pero non substitúe a autenticación do usuario ou do dispositivo.

Manteña as probas etiquetadas: orixe observada, conta autenticada, momento e a inferencia considerada. Non traduza «aquí non se ve ningunha orixe interna» por «non é posible ningunha atribución en ningún lugar». A etiqueta importa cando alguén que non formou parte da investigación le o rexistro meses despois.

Rexistre a data da observación e o sistema que a produciu. Un extracto de rexistro sen atribución é difícil de defender máis tarde.