Como chamar uma API interna de um app de iPhone por VPN

A API responde no Safari no mesmo telefone, enquanto a requisição do app expira. Essa diferença geralmente não é o túnel: um app que chama um serviço interno faz uma requisição HTTPS comum, e a VPN que já existe no dispositivo só decide se essa requisição tem caminho. Escrever um segundo túnel no app é uma decisão de produto, não um reparo para um tempo esgotado. O que segue classifica a falha pelo local onde ela ocorre, usando a superfície de erros que o app já tem.

Comece pelo erro, não pelo túnel

URLSession relata falhas de transporte como NSError valores em NSURLErrorDomain, e o código é a evidência mais barata disponível. Antes de mudar qualquer configuração, registre esse código junto com o nome do host que falha e o tempo decorrido da tarefa. Um tempo esgotado, uma falha de nome e uma falha de confiança parecem iguais na tela e exigem três reparos diferentes. Classifique primeiro e depois leia a seção dessa classe.

As métricas da tarefa respondem à pergunta seguinte, se alguma vez se estabeleceu uma conexão, o que separa uma requisição que nunca teve rota de uma em que o servidor demorou demais a responder. Nada disso exige mudar o túnel; exige que os diagnósticos da própria requisição sejam impressos em algum lugar que você possa ler.

A resolução de nomes falha antes de qualquer outra coisa

Um nome de escritório curto como api.corp.example geralmente depende de um domínio de busca que o telefone não carrega, então o app resolve um nome que só existe dentro do prédio. NSURLErrorCannotFindHost é a assinatura. O nome de host completo precisa ser resolvido pelo resolver que a VPN instalar, e o app deve pedir a forma totalmente qualificada sempre que o domínio de busca não for garantido. Trocar o nome por um endereço e desligar as verificações de certificado move a falha em vez de corrigi-la.

Um registro DNS privado e um certificado emitido para esse nome exato são o par suportado. Todo o resto é um contorno que chega aos usuários.

Um tempo esgotado é uma questão de rota, não de nome

NSURLErrorTimedOut significa que o nome foi resolvido e nada respondeu, o que aponta para a rota, a política de pacotes ou o serviço. Quando o túnel é atribuído por aplicação, outro app que alcança o mesmo servidor não diz nada sobre sua compilação, porque esse mapeamento não é compartilhado. Verifique se o pacote que você executa está dentro dessa atribuição e depois verifique se o caminho do serviço é permitido para ele. Uma compilação de desenvolvimento instalada fora da atribuição pode ficar completamente fora do túnel e parecer uma API quebrada.

Uma comparação no navegador mostra que algum app no dispositivo tem caminho. Ela nunca prova que a sua compilação tem, e por isso os dois testes precisam ser executados separadamente.

As falhas de confiança dizem respeito ao nome no certificado

NSURLErrorServerCertificateUntrusted junto com o erro TLS por baixo significa que a cadeia ou a verificação de identidade falhou. Uma CA interna precisa ser confiável no dispositivo, e um certificado emitido para outro nome de host continua errado depois de qualquer reconfiguração de rede. As orientações de App Transport Security da Apple continuam a aplicar-se a essas conexões que carregam URL, e um túnel em torno de um serviço HTTP simples não torna esse serviço seguro de ponta a ponta.

Corrija a identidade ou a âncora de confiança e mantenha a lista de exceções vazia. Uma exceção geral para carregamento arbitrário esconde a falha durante o desenvolvimento e a deixa no lugar para cada usuário depois.

Uma rejeição HTTP pertence ao app, não à rede

Um 401 ou 403 após um handshake concluído significa que a requisição chegou e o serviço a recusou, então a pergunta restante é uma conta, um público de token, um escopo ou uma chave. Registre o código de status e o nome do host, nunca o token de portador nem o corpo da resposta. Nesse ponto o túnel faz o seu trabalho e mais mudanças de rede só atrasam o reparo real.

A tabela é a classificação que deve ficar ao lado do terminal: uma linha por falha que o app realmente consegue relatar. Imprima o código antes de lê-lo, porque a linha que você escolher decide qual seção você percorre.

Cada linha é mais barata de testar do que a de baixo, e cada uma descarta uma camada diferente da mesma requisição. Desça pela tabela até uma linha coincidir e depois pare de mudar a rede.