Ping da interface fictícia

Não existe "o outro lado" (exceto talvez um vazio) com uma interface fictícia. Em outras palavras, não é realmente diferente de lo, exceto que normalmente se configuraria um endereço de um bloco diferente do bloco de loopback ( 127.0.0.0/8). (Para ser franco, não tenho certeza se, em alguma circunstância, alguém poderia literalmente precisar de uma interface fictícia atualmente. Parece-me que ela existe por razões mais históricas.)

De qualquer forma, o verdadeiro problema aqui não é exatamente o dummy, mas o -Iin ping. Já vi muitas pessoas terem mal-entendidos semelhantes, mas mal consegui ver/adivinhar de onde isso vem, então só posso esperar que a explicação a seguir possa ajudá-lo a sair dessa:

Se interface for um nome de interface, ele define a interface de origem como interface especificada.

O fato de você poder usar uma interface como uma "interface de origem" NÃO significa que você pode emular/simular um "host de origem", como quando você faz ping de uma rede diferente. A frase aqui realmente significa apenas que "ignore rotas que tenham uma interface diferente ( dev)", ou em outras palavras, "garanta (certifique-se) que o tráfego saia apenas por meio desta interface, não importa o que aconteça". (Parece que se o destino não for coberto por nenhuma rota dessa interface, o destino seria considerado "onlink".)

Em outras palavras, “interface de origem” NÃO significa “interface de entrada”.

Portanto, quando você usa -Iuma interface fictícia, o único destino que poderia fazer sentido seria o IP configurado no próprio manequim, o que resultaria em tráfegos de loopback . Obviamente, esses tráfegos nunca sairiam do host por meio de outra interface como enp1s0. (Aparentemente, os tráfegos de loopback nem podem ser DNATinseridos em PREROUTING.) Os tráfegos destinados a, por exemplo, 8.8.8.8não iriam a lugar nenhum (mas seriam vazios).

(NOTA: Na verdade, precisamente falando, o tráfego de loopback não sai do host, então suponho que, pelo menos em certo sentido, você pode considerar isso uma "exceção" em -I"tornado possível" com a localrota correspondente, porque o manequim interface ainda é sua interface de rota, mesmo quando faz com que o tráfego seja retornado e "ingresse" no host via lo.)

Dito isso, uma regra SNAT(not MASQUERADE) que corresponda apenas (ou seja, não -o enp1s0) a um endereço de origem (bloco) (por exemplo, -s 10.0.0.0/24) "funcionaria" para tais tráfegos de loopback. Só que não consigo ver qual seria o sentido de realizar esse "teste".

Para "testar" uma MASQUERADEregra, você precisaria de tráfegos que saíssem através da interface específica (por exemplo enp1s0, ). Portanto, você precisaria (bem, um pouco; veja a última seção) de outro "host" para ser o "host de origem", que formaria uma rede com esse host e, portanto, teria um IP de origem de alguma sub-rede IP diferente da aquele usado pela rede à qual a interface (por exemplo, enp1s0) está conectada e, portanto, precisa ser mascarada (se esse "outro lado" não tiver rota de retorno para esta sub-rede).

E hoje em dia a maneira mais fácil de "criar" um host de rede/(em termos de rede) é o par netns + veth.

Observe que isso -Ifunciona de maneira muito diferente quando você usa um endereço IP em vez de uma interface como argumento.

Se interface for um endereço, ele define o endereço de origem para o endereço de interface especificado.

AFAIK, neste caso, não afeta a decisão da rota. Basicamente, ele apenas define o endereço IP de origem dos tráfegos de antemão, em vez de deixá-lo sem definição e deixar o sistema escolher um para ele com base em/após a decisão da rota.

Portanto, uma MASQUERADEregra é realmente necessária e “funcionaria” para:

ping -I 10.0.0.10 8.8.8.8

Mas então a questão é: o que significa quando você não está testando com a coisa real (NÃO estou falando sobre um "teste de rede") que a MASQUERADEregra deve servir?