Android-VPN lost de folsleine hostnamme op, mar net de koarte namme

Jo typefilesyn in terminalemulator en der komt neat werom; jo typefiles.corp.exampleen deselde tsjinner antwirdet daliks. Oan de VPN-oanmeldgegevens is neat feroare, en de privee DNS-tsjinner wie nea stikken. Yn Android nimme de koarte namme en de folsleine namme ferskillende paaden troch de oplosser, en ien fan dy paaden hinget ôf fan in ynstelling dy't de eigner fan de tunnel leverje moat. De beslissing foar jo is net hokker DNS-tsjinner jo feroarje, mar wa't it netwurk kontrolearret dat de app eins brûkt.

In sykdomyn is gjin adres. It is in list fan efterheaksels dy't de oplosser oan in neaken namme taheakket foardat er it opjout.

In sykheaksel en in DNS-tsjinner binne aparte fjilden

It adres fan de oplosser fertelt Android wêr't frege wurde moat. It sykheaksel fertelt wat frege wurde moat as jo allinnich de loftske namme jouwe. Beide libje op itselde netwurkobjekt, en elk kin op himsels ûntbrekke.

Dy ûnôfhinklikens is krekt de reden dat de folsleine hostnamme wurket. In folslein kwalifisearre namme hat gjin efterheaksel nedich, om't it al de tekenrige is dy't nei de tsjinner giet.

Android lit de skieding sjen fiaLinkProperties. De list fan DNS-tsjinners en de list foar domeinsykjen steane op itselde objekt, en de twadde is gauris leech sels as de earste fol is. In netwurk mei in oplosser mar sûnder domein is in netwurk dêr't it efterheaksel nea tapast is — net in tsjinner dy't de koarte namme wegere.

Lês it effektive netwurk foardat jo wat feroarje

Wi-Fi, mobyl netwurk en in VPN-ynterface binne trije aparte netwurken, en de tunnel wurdt de standert sadree't er omheech komt. It efterheaksel dat op it kantoar-Wi-Fi wurke, is dus net automatysk it efterheaksel dat jildt wylst de tunnel aktyf is. Besjoch it netwurk dêr't de app echt op selektearre is, net dat jo ferline wike konfigurearre hawwe.

In terminalskel op it apparaat is hjir in minne getuige, om't synresolv.confien eachpunt op de oplosser wjerstrielet en net dat fan elke app.

Adresbalken fan browsers foegje noch in laach ta: in neaken wurd kin as sykopdracht behannele wurde, of oplost wurde fiait eigen belied fan 'e browser foar fersifere DNS, dat in side dy't yn Chrome laden wurdt bewiist neat oer systeemsykjen. Test mei eat dat de oplosser fan it platfoarm brûkt en printsjet wat weromkaam. Rin dan de koarte en de folsleine foarm yn deselde sesje, op itselde netwurk, en notearje hokker in antwurd joech.

As jo de VPN-app bouwe, heakje it efterheaksel dan yn 'e bouwer ta

As jo app de ynterface oprjochtet fiaVpnService,addSearchDomainis de stipe ynfier dêrfoar. It nimt in domeintekenrige lykascorp.example, en it is gjin alternative manier om in tsjinneradres troch te jaan.

De oprop bynt it efterheaksel oan it netwurk dat jo bouwe, dus der is gjin globale ynstelling om dêrnei om te setten. As de app de ynterface ôfbrekt en by opnij ferbinen wer opbouwt, moat de nije bouwer it efterheaksel wer taheakje, oars komt it ferfangende netwurk sûnder it omheech.

Hjir ferlieze in protte ymporten fan buroblêdprofyl it fjild. De eksporteur skriuwt it domein yn syn eigen model, it Android-frontend mapt allinnich de opsjes dy't it ken, en de resultearjende ynterface sjocht der yn alle oare opsichten goed út. In profyl dat op in laptop wurket en op in tillefoan mislearret, is meastentiids in gat yn 'e mapping, gjin protokolprobleem.

As jo allinnich de VPN brûke, is dit net oan jo om te setten

Der is gjin bewurking oan 'e kliïntkant dy't in efterheaksel taheakket, en gjin globale eigenskip dy't jo feroarje kinne om ien te ferrifeljen. De wearde wurdt levere troch wa't de tunnel hat: yn it profyl fan 'e behearder kliïnt, yn syn mapping per platfoarm, of fia wat de tsjinner stjoert. Sis op hokker platfoarm jo binne en hokker namme mislearret, om't de buroblêd- en mobyfrontends krekt op dit fjild ferskille.

It opnij ymportearjen fan in buroblêdprofyl bewiist wer neat oer de mobylmapping.

Trije betingsten beslisse oft jo in defekt hawwe of in ferwachte beheining. Earst, behannelet de organisaasje de koarte namme hielendal as in stipe namme, of is it in gemak dat ea allinnich op it kantoar-Wi-Fi wurke hat? Twad, komt it mislearjende sykjen fan in browser, dy't de systeemoplosser folslein omgean kin? Tred, moat de koarte namme berikber wêze fia de tunnel, of allinnich fan it LAN? As it lêste antwurd allinnich-LAN is, soe it taheakjen fan in efterheaksel in namme meitsje dy't bûten it kantoar oplost en dan net rûte wurdt.

As it efterheaksel oanwêzich is en koarte nammen noch mislearje

As de list foar domeinsykjen alcorp.examplesjen lit, stop dan mei it efterheaksel de skuld te jaan. Kontrolearje oft de oplosser alteast in antwurd jout foar de útwreide namme, om't in efterheaksel allinnich de fraach feroaret dy't jo stelle. It makket de tsjinner nea gesachhawwend foar in sône dy't er net host.

Kontrolearje dan de rûte. In adres dat oplost mar net troch de tunnel droegen wurdt, mislearret by ferbinen, wat der identyk útsjocht as in mislearre sykjen yn in browser dy't stil opjout.

Sertifikaten fertsjinje in eigen neaming. HTTPS-falidaasje brûkt de hostnamme dy't jo echt typt hawwe, dus in koarte namme dy't korrekt útwreidet, presintearret noch altydfilesby de hânskodding. In sertifikaat dat útjûn is foarfiles.corp.examplesil dêrfoar net falidearje, en dy flater is korrekt gedrach en gjin symptoom fan it DNS-probleem dêr't jo mei begûn binne.

Wat no te dwaan

Befêstigje de skieding foardat jo wat oanreitsje: de folsleine namme lost op, de koarte net, deselde app, deselde sesje. Fyn dan it selektearre netwurk en lês syn list foar domeinsykjen njonken syn list fan oplossers. Hokker fan de twa leech is, fertelt jo wa't hannelje moat — jo, as jo de app hawwe; de tunneleksploitant, as jo dy net hawwe.

Kies úteinlik de folsleine tsjinsthostnamme yn blêdwizers en kliïntkonfiguraasje dêr't oerdraachberens ta docht. It oerlibbet in netwurkwiksel, it hinget net ôf fan in mapping dy't it mobyfrontend miskien net ymplemintearret, en it komt oerien mei de namme dêr't in sertifikaat foar útjûn is.