Como chamar unha API interna desde unha app de iPhone por VPN

A API responde en Safari no mesmo teléfono, mentres que a solicitude da app esgota o tempo. Esa fenda normalmente non é o túnel: unha app que chama un servizo interno fai unha solicitude HTTPS normal, e a VPN que xa ten o dispositivo só decide se esa solicitude ten ruta. Escribir un segundo túnel dentro da app é unha decisión de produto, non unha reparación para un tempo de espera. O que segue clasifica o fallo segundo onde ocorre, usando a superficie de erros que a app xa ten.

Empece polo erro, non polo túnel

URLSession informa os fallos de transporte como NSError valores en NSURLErrorDomain, e o código é a evidencia máis barata da que dispón. Antes de cambiar calquera configuración, rexistre ese código xunto co nome de host que falla e o tempo transcorrido da tarefa. Un tempo de espera, un fallo de nome e un fallo de confianza vense igual na pantalla e esixen tres reparacións distintas. Clasifique primeiro e despois lea a sección desa clase.

As métricas da tarefa responden á seguinte pregunta, se algunha vez se estableceu unha conexión, o que separa unha solicitude que nunca tivo ruta dunha á que o servidor tardou demasiado en responder. Nada disto necesita cambiar o túnel; necesita que os diagnósticos da propia solicitude se impriman nun lugar que poida ler.

A resolución de nomes falla antes que calquera outra cousa

Un nome de oficina curto como api.corp.example adoita depender dun dominio de busca que o teléfono non leva, así que a app resolve un nome que só existe dentro do edificio. NSURLErrorCannotFindHost é a sinatura. O nome de host completo debe resolverse mediante o resolver que instale a VPN, e a app debería pedir a forma totalmente cualificada sempre que o dominio de busca non estea garantido. Cambiar o nome por un enderezo e desactivar as comprobacións de certificados move o fallo en lugar de reparalo.

Un rexistro DNS privado e un certificado emitido para ese nome exacto son a parella admitida. Todo o demais é unha volta que chega aos usuarios.

Un tempo de espera é unha cuestión de ruta, non de nome

NSURLErrorTimedOut significa que o nome se resolveu e nada respondeu, o que apunta á ruta, á política de paquetes ou ao servizo. Cando o túnel se asigna por aplicación, outra app que chega ao mesmo servidor non di nada sobre a súa compilación, porque ese mapeo non se comparte. Comprobe que o paquete que executa está dentro desa asignación e despois comprobe que a ruta do servizo está permitida para ese paquete. Unha compilación de desenvolvemento instalada fóra da asignación pode quedar completamente fóra do túnel e parecer unha API rota.

Unha comparación no navegador mostra que algunha app do dispositivo ten ruta. Nunca demostra que a súa a teña, e por iso as dúas probas deben executarse por separado.

Os fallos de confianza teñen que ver co nome no certificado

NSURLErrorServerCertificateUntrusted xunto co erro TLS que hai debaixo significa que a cadea ou a comprobación de identidade fallou. Unha CA interna debe ser de confianza no dispositivo, e un certificado emitido para outro nome de host segue estando mal despois de calquera reconfiguración de rede. A guía de App Transport Security de Apple segue aplicándose a estas conexións que cargan URL, e un túnel arredor dun servizo HTTP simple non fai que ese servizo sexa seguro de extremo a extremo.

Corrixa a identidade ou a áncora de confianza e manteña a lista de excepcións baleira. Unha excepción xeral para carga arbitraria oculta o fallo durante o desenvolvemento e déixao no seu sitio para cada usuario despois.

Un rexeitamento HTTP pertence á app, non á rede

Un 401 ou 403 tras un handshake completado significa que a solicitude chegou e o servizo rexeitouna, así que a pregunta restante é unha conta, unha audiencia de token, un ámbito ou unha clave. Rexistre o código de estado e o nome de host, nunca o token de portador nin o corpo da resposta. Nese punto o túnel fai o seu traballo e máis cambios de rede só atrasan a reparación real.

A táboa é a clasificación que convén ter xunto ao terminal: unha fila por cada fallo que a app pode informar de verdade. Imprima o código antes de lelo, porque a fila que elixa decide que sección traballa.

Cada fila é máis barata de probar que a de abaixo, e cada unha descarta unha capa distinta da mesma solicitude. Baixe pola táboa ata que unha fila coincida e despois deixe de cambiar a rede.