Porque a sua aplicação de iPhone mostra um IP e o servidor regista outro
Um endereço de interface, um endpoint de socket e a origem que um servidor regista respondem a perguntas diferentes. Uma VPN acrescenta contexto; não as torna um único número.
Chegam tickets de suporte dizendo que a aplicação mostra um endereço enquanto o servidor registou outro, e depois perguntam qual dos dois mente. Nenhum mente; são duas observações de duas coisas diferentes. Um endereço ligado a uma interface, um endereço ligado a um socket e um endereço de origem visto por um serviço remoto respondem a três perguntas separadas. Uma VPN acrescenta um contexto de rede ao telefone e não colapsa esses três num único número para todo o dispositivo. Leia os nomes dos campos do ticket antes de ler os endereços.
O que o ticket costuma descrever
Imagine um telefone em Wi-Fi com um túnel levantado. A interface Wi-Fi tem um endereço LAN, a interface do túnel tem um endereço interno atribuído, e um pedido que sai pelo túnel chega a um serviço público a partir da origem que sobreviver a qualquer tradução no caminho. Uma aplicação que imprime o endereço interno e um servidor que registra a origem traduzida relatam ambos com precisão, e os dois valores nunca coincidirão.
As três observações diferem no que podem provar, não apenas no que descrevem.
| Observation | What it describes | What it cannot prove |
|---|---|---|
| An address on a local interface | One configured attachment: Wi-Fi, cellular or a tunnel | The source a remote site receives |
| A socket's local endpoint | The binding used by that one connection | The address after translation further along |
| The peer address at a service | What arrived at that observation point | Any other interface on the phone |
Mantenha essa tabela junto do código que preenche estes valores num ticket, porque a maior parte da confusão aqui é uma troca de colunas e não uma falha de rede.
O que uma chamada de socket pode e não pode responder
Ao nível da API, getsockname reporta o endpoint local atualmente ligado a um socket específico. Para um socket ligado, essa é a origem que o núcleo escolheu para essa ligação, o que já é mais específico do que qualquer listagem de interfaces. Não é uma consulta de endereço público, e chamá-lo num socket não ligado não lhe diz quase nada. O que devolver pode ainda ser reescrito mais adiante no caminho, por isso apenas a observação do próprio serviço é autoritativa sobre o que o serviço recebeu.
Nas plataformas Apple, o lado das interfaces tem uma superfície separada: as definições do túnel listam os endereços atribuídos à interface do túnel. Lê-las diz-lhe como o túnel foi configurado, e não lhe diz que caminho seguiu um dado pedido, porque o encaminhamento e as regras por aplicação decidem isso para cada ligação.
O túnel dividido torna a diferença visível. Um pedido pode sair pelo túnel enquanto o seguinte, dirigido a outro destino ou família de endereços, não sai, pelo que dois resultados da mesma aplicação com segundos de diferença podem ser honestos e diferentes.
Escolha a observação que corresponde à pergunta
Escolha deliberadamente em vez de instrumentar tudo. Para o que o backend vê, registe a origem no backend, e onde houver um proxy inverso à frente, leia o endereço do cliente a partir do cabeçalho de reencaminhamento que a sua implementação realmente define, e não de nada que o cliente tenha enviado.
Para saber se o túnel está configurado, leia a interface. Para saber se o tráfego desta aplicação o usou, envie tráfego dessa aplicação para um destino que controle e compare a origem nas duas pontas.
As regras por aplicação merecem a sua própria frase. O resultado de um navegador é evidência sobre esse navegador, e um túnel gerido por aplicação pode colocar duas aplicações no mesmo telefone em caminhos diferentes no mesmo momento. Verificar a cobertura significa enviar tráfego a partir da aplicação em questão, na família de endereços em questão.
Os nomes das interfaces não são um detetor
Também não use um nome de interface como verificação de VPN. Os nomes não são um contrato público, e um telefone pode ter vários anexos enquanto apenas um deles transporta o seu pedido.
Dê ao campo o nome da observação que contém. local_interface_address, socket_local_endpoint e service_observed_source são desajeitados e inequívocos, e inequívoco é o que quer quando o valor acaba num ticket de suporte uma semana depois. Uma única coluna chamada device IP recolherá as três e depois será confiada como se fosse uma.
Mantenha a identidade fora da coluna do endereço
Uma saída VPN partilhada não é uma identidade de utilizador, e um endereço privado não é uma credencial de acesso. Ambos descrevem um caminho e não uma pessoa, e tratar qualquer um deles como autenticação transforma um acidente de encaminhamento numa decisão de autorização.
Quando alguém pergunta que endereço tem o telefone, a resposta útil é uma pergunta sobre que ligação e que observador. A definição de getsockname vale a pena citar para o caso intermédio, porque resolve a questão do socket sem fingir resolver as outras duas.
Depois anote qual dos três o seu produto realmente precisa de mostrar, e apague os outros dois da interface.