Si të telefononi një API të brendshme nga një aplikacion iPhone përmes VPN

API përgjigjet në Safari në të njëjtin telefon, ndërsa kërkesa e aplikacionit skadon. Ky hendek zakonisht nuk është tuneli: një aplikacion që thërret një shërbim të brendshëm bën një kërkesë normale HTTPS, dhe VPN që ekziston tashmë në pajisje vendos vetëm nëse kjo kërkesë ka një rrugë. Të shkruash një tunel të dytë në aplikacion është një vendim produkti, jo një riparim për një skadim. Ajo që vijon e klasifikon dështimin sipas vendit ku ndodh, duke përdorur sipërfaqen e gabimeve që aplikacioni e ka tashmë.

Filloni nga gabimi, jo nga tuneli

URLSession raporton dështimet e transportit si NSError vlera në NSURLErrorDomain, dhe kodi është prova më e lirë e disponueshme. Përpara se të ndryshoni çdo konfigurim, regjistroni atë kod së bashku me emrin e hostit që dështon dhe kohën e kaluar të detyrës. Një skadim, një dështim emri dhe një dështim besimi duken njësoj në ekran dhe kërkojnë tre riparime të ndryshme. Së pari klasifikoni, më pas lexoni seksionin për atë klasë.

Metrikat e detyrës përgjigjen pyetjes vijuese, nëse ndonjëherë u vendos një lidhje, gjë që ndan një kërkesë që nuk kishte kurrë rrugë nga një që serveri vonoi shumë për t'u përgjigjur. Asgjë nga kjo nuk kërkon ndryshim të tunelit; kërkon që diagnostifikimi i vetë kërkesës të printohet diku ku mund ta lexoni.

Zgjidhja e emrave dështon përpara çdo gjëje tjetër

Një emër i shkurtër zyre si api.corp.example zakonisht varet nga një domain kërkimi që telefoni nuk e mban, kështu që aplikacioni zgjidh një emër që ekziston vetëm brenda ndërtesës. NSURLErrorCannotFindHost është firma. Emri i plotë i hostit duhet të zgjidhet përmes çdo resolversi që instalon VPN, dhe aplikacioni duhet të kërkojë formën plotësisht të kualifikuar sa herë që domaini i kërkimit nuk është i garantuar. Zëvendësimi i emrit me një adresë dhe çaktivizimi i kontrolleve të certifikatave e zhvendos dështimin në vend që ta rregullojë.

Një regjistrim privat DNS dhe një certifikatë e lëshuar për saktësisht atë emër janë çifti i mbështetur. Çdo gjë tjetër është një anashkalim që arrin te përdoruesit.

Një skadim është çështje rruge, jo çështje emri

NSURLErrorTimedOut do të thotë që emri u zgjidh dhe asgjë nuk u përgjigj, gjë që të çon te rruga, politika e paketave ose shërbimi. Kur tuneli caktohet për çdo aplikacion, një aplikacion tjetër që arrin të njëjtin server nuk thotë asgjë për ndërtimin tuaj, sepse ai hartëzim nuk ndahet. Kontrolloni që paketa që ekzekutoni është brenda atij caktimi, më pas kontrolloni që rruga e shërbimit është e lejuar për të. Një ndërtim zhvillimi i instaluar jashtë caktimit mund të qëndrojë plotësisht jashtë tunelit dhe të duket si një API e thyer.

Një krahasim në shfletues tregon se ndonjë aplikacion në pajisje ka një rrugë. Ai nuk provon kurrë se ndërtimi juaj e ka një të tillë, prandaj dy testet duhet të kryhen veçmas.

Dështimet e besimit kanë të bëjnë me emrin në certifikatë

NSURLErrorServerCertificateUntrusted së bashku me gabimin TLS poshtë tij do të thotë që zinxhiri ose verifikimi i identitetit dështoi. Një CA e brendshme duhet të jetë e besuar në pajisje, dhe një certifikatë e lëshuar për një emër tjetër hosti mbetet e gabuar pas çdo rikonfigurimi të rrjetit. Udhëzimet App Transport Security të Apple vazhdojnë të zbatohen për këto lidhje që ngarkojnë URL, dhe një tunel rreth një shërbimi të thjeshtë HTTP nuk e bën atë shërbim të sigurt nga një skaj në tjetrin.

Rregulloni identitetin ose ankorën e besimit dhe mbani listën e përjashtimeve bosh. Një përjashtim i përgjithshëm për ngarkim arbitrar fsheh dështimin gjatë zhvillimit dhe e lë në vend për çdo përdorues më pas.

Një refuzim HTTP i përket aplikacionit, jo rrjetit

Një 401 ose 403 pas një shtrëngimi duarsh të përfunduar do të thotë që kërkesa mbërriti dhe shërbimi e refuzoi, kështu që pyetja e mbetur është një llogari, një audiencë tokeni, një fushë veprimi ose një çelës. Regjistroni kodin e statusit dhe emrin e hostit, kurrë tokenin mbajtës ose trupin e përgjigjes. Në atë moment tuneli po bën punën e tij dhe ndryshime të tjera të rrjetit vetëm sa vonojnë rregullimin e vërtetë.

Tabela është klasifikimi që duhet mbajtur pranë terminalit: një rresht për çdo dështim që aplikacioni vërtet mund të raportojë. Printoni kodin përpara se ta lexoni, sepse rreshti që zgjidhni vendos se cilën pjesë do të punoni.

Çdo rresht është më i lirë për t'u testuar se ai poshtë tij, dhe secili përjashton një shtresë tjetër të së njëjtës kërkesë. Zbrisni tabelën derisa një rresht të përputhet, më pas ndaloni së ndryshuari rrjetin.