Como host.docker.internal funciona no Windows

Deixe-me ilustrar com diagramas a diferença entre o caso de ter o mecanismo docker rodando diretamente em um host Linux e o caso do Docker Desktop (que é mais ou menos o único caso no Windows, porque o Windows não é Linux):

Observe que os diagramas nesta resposta ilustram as "estruturas de rede". É por isso que você vê que os contêineres estão "fora" do host Linux. Pelo menos para um host Linux, você pode acessá-lo com um IP configurado em qualquer uma de suas interfaces. Portanto, essencialmente, você pode acessar o host do docker com o IP configurado em eth0, docker0, some br-xxx(pontes docker não padrão) ou qualquer outro que exista no namespace de rede "padrão" (netns). Em termos de rede, uma rede diferente é muito parecida com um host diferente, e é por isso que os contêineres docker, cada um com suas próprias redes, são como hosts separados em LANs "virtuais" (no sentido de "emulados"; de qualquer forma, não "VLAN "). As docker bridges são como switches virtuais, com uma de suas portas conectada ao host e as outras conectadas aos contêineres. Portanto, o host docker está conectado a várias LANs (domínios de transmissão) e serve como um roteador para os contêineres. (Você pode ver mais ou menos eth0como a "interface WAN" no ponto de vista dos contêineres.)

Quando se trata do gabinete do Docker Desktop, é como aninhar o gabinete "bare metal" do Linux em uma VM. Uma VM é obviamente como um "host separado" como um contêiner e, pelo menos por padrão, também está conectada a um "switch interno", que é como uma ponte docker para os contêineres, e por causa disso, você faria ser capaz de acessar o host do Windows com o IP configurado nesse switch (você também pode vê-lo como uma NIC virtual conectada a uma porta desse switch).

Observe que a opção não é realmente "uma parte do docker", mas apenas uma parte do WSL/Hyper-V. O IP/sub-rede privado usado também não é escolhido pelo docker.

3. Como o IP host.docker.internal pode ser resolvido para o IP do host se não estiver no meu ipconfig no Windows ou em qualquer outro dispositivo na rede do host?

Eu realmente não olhei para o código do docker (na verdade, ele pode nem estar aberto, já que o Docker Desktop consiste em blobs, eu acho), mas acredito que as "respostas" do DNS host.docker.internalsão derivadas do endereço do gateway na rota padrão ( ou seja, gateway padrão) da VM. (Para ser franco, eu nem verifiquei no Windows. Eu apenas "verifiquei os fatos" executando o Docker Desktop no Linux, que executa KVM com qemu.) O gateway padrão é anunciado à VM pelo hipervisor por meio de DHCP.

Eu realmente não tenho a razão exata pela qual a Microsoft decidiu "ocultar" algumas das opções internas (bem, as "padrão"/"especiais"), mas IIRC, o fato de elas estarem ocultas não significa necessariamente que você não pode acessar o host do Windows com o IP configurado nesses switches.

Não sei exatamente se você pode acessar um host Windows a partir de uma rede com IP configurado em um adaptador que NÃO está conectado à rede (como você pode acessar um host Linux).

4. Qual seria o fluxo do pacote Win?

De qualquer forma, os adaptadores não são hosts separados; não existe "fluxo" do adaptador para outro adaptador quando você está falando no mesmo host de destino. Quando os tráfegos chegam a um host por meio de uma interface, eles chegam. Eles só passariam por outra (ou a mesma) interface se seu destino "final" não fosse o host, mas algum outro host, caso em que ocorreria o encaminhamento L3/IP (basicamente, isso significa que o host funciona como um gateway/roteador e o tráfego vai de uma rede para outra rede ocasionalmente, a mesma). Por exemplo, se seus contêineres tentarem acessar o Google ou um dispositivo em sua LAN doméstica.

2. Então no caso do Windows o 172.17.0.1 é o IP do docker0 como você disse, seria como o IP de um roteador em uma rede ou como um IP de dispositivo switch (eu sei que eles não têm em uma rede real)?

Eu realmente não entendi a pergunta, mas sim (suponho?), 172.17.0.1é um "IP do roteador", no sentido de que o host Linux (que executa os contêineres, independentemente de ser uma VM) é um roteador / ( padrão) gateway para os contêineres. Observe que você pode ter mais de uma ponte docker e 172.17.0.1é apenas o endereço usual configurado no padrão ( docker0). Os contêineres realmente teriam seu gateway padrão definido para o endereço IP configurado na ponte docker à qual estão conectados.

Pode valer a pena mencionar que host.docker.internalé "específico do Docker Desktop", ou seja, por padrão / OOTB você não obterá nenhuma resposta para isso no caso "bare metal", embora pareça que alguma "infraestrutura" foi adicionada para permitir que você para "imitar" algo semelhante. (Eu realmente não verifiquei se a "infraestrutura" forneceria o IP configurado em uma respectiva ponte docker ou o gateway padrão no host Linux.)

Além disso, gateway.docker.internalisso (também) mencionado aqui dá a mesma resposta host.docker.internal(pelo menos quando o Docker Desktop é executado no Linux). Ainda não tenho certeza se, em alguma circunstância, eles poderiam dar respostas diferentes.