Parece que o computador B está atrás de um roteador NAT. Se isso for verdade, então cada máquina por trás desse roteador parecerá ter o mesmo endereço IP do ponto de vista do computador A.
Quando o NAT está envolvido, o tráfego de saída faz com que o roteador NAT lembre o originador desse tráfego por um tempo, de modo que quando o tráfego é recebido do mesmo endereço IP de destino, o roteador NAT sabe quem deve "dar" o tráfego de volta para. "
Quando o roteador NAT recebe tráfego inesperado do "fora", ele não sabe para quem "devolver o tráfego", a menos que você o informe com regras de encaminhamento de porta.
O NAT não está realmente preocupado com o tipo de tráfego, exceto que alguns protocolos não funcionam bem com o NAT por padrão, porque os endereços IP são codificados na carga útil dos protocolos. Normalmente, o NAT modifica apenas o campo de IP de origem dos pacotes, mas no caso de coisas como FTP "auxiliar" "pode ser necessário que modifique a carga real do pacote .
Um firewall pode "bloquear" um pacote, de qualquer tipo, por:
- enviando uma mensagem ICMP de volta dizendo que o pacote foi rejeitado por um motivo específico
- simplesmente não está respondendo
- então há coisas hacky como tarpits .
A única forma de "estado" afeta o fato de que um firewall geralmente tratará novas conexões TCP de maneira muito diferente das existentes - haverá tráfego "novo" e "estabelecido".
O UDP, por definição, NÃO é um protocolo orientado à conexão, portanto, não há nenhum estado a ser monitorado no que diz respeito às camadas OSI 2-4. Todas as conexões UDP de entrada são tratadas como "novas" ou iguais.
O servidor ou cliente que usa o UDP para se comunicar pode acompanhar algum estado (um pouco de estado é necessário para que coisas como TFTP funcionem - o cliente / servidor TFTP rastreiam isso por conta própria). Mas a pilha TCP / IP não deveria.