Androidin aina päällä oleva VPN: miten päätepisteen nimi ratkaistaan ensin

Puhelin käynnistyy uudelleen, aina päällä on käytössä, yhteyksien estäminen ilman VPN:ää on päällä, eikä tunneli nouse koskaan. Mikään ei ole väärin määritetty: esto tekee tehtävänsä, ja asiakkaan oma yritys päästä päätepisteeseensä on myös sen alainen. Päätepiste on ratkaistava ennen kuin tunneli on olemassa, asiakkaan toimesta, jolla on lupa puhua verkolle, kun taas millään muulla sovelluksella ei ole. Ymmärrys siitä, mikä osa sen tekee ja missä järjestyksessä, muuttaa mysteerin kokoonpanokysymykseksi.

Mitä VPN-rakentaja oikeastaan pyytää

Android VPN -sovellus ei anna alustalle palvelimen osoitetta. Se rakentaa paikallisen rajapinnan: osoitteet ja reitit tunnelille, resolverit, joita sovellusten on käytettävä sisällä, ja sitten establish() palauttaa tiedostokuvauksen, jota sovellus lukee ja kirjoittaa raakoina IP-paketteina. Etäinen päätepiste ei esiinny siinä rakentajassa lainkaan.

Tämä on keskeinen rakenteellinen tosiasia. Alusta luo tun-rajapinnan ja valvoo siinä käytäntöä; sovellus toteuttaa siirron käyttäjän tilassa, eli sovellus itse ratkaisee päätepisteensä nimen ja avaa salatun yhteyden. Isäntänimi päätepisteenä on siis mahdollinen, ei siksi että alusta tukisi nimiä, vaan siksi että alusta ei koskaan näe päätepistettä.

Yksi rakentajan kenttä ottaa osoitteita: DNS-palvelimet. Niiden on oltava numeerisia resolveriosoitteita, yleensä niitä, joita operaattori haluaa kysyttävän tunnelin kautta. Kenttä kuvaa, mihin sovellukset lähettävät kyselynsä, kun tunneli on ylhäällä. Se ei kerro mitään siitä, miten asiakas löytää päätepisteen, ja molempien pitäminen samana asetuksena on sekaannuksen alku.

Kaksi DNS-kysymystä, ei yksi

Ensimmäinen kysymys on: mihin sovellukset lähettävät kyselynsä, kun tunneli on ylhäällä? Vastaus on resolveriosoite tunnelin sisällä, tavoitettavissa tun-rajapinnan kautta, rakenteellisesti numeerinen.

Toinen kysymys on: miten asiakas löytää oman päätepisteensä ennen kuin tunneli on olemassa? Haku tapahtuu tunnelin ulkopuolella, taustaverkossa, asiakkaan prosessissa. Se voi käyttää nimeä, ja sen on käytettävä resolveria, johon laite pääsee ilman VPN:ää.

Kolme vaihetta, kolme erilaista oiretta. Yksi virheilmoitus kuten ei voi yhdistää sulauttaa ne, ja siksi ihmiset muokkaavat DNS-palvelinkenttää korjatakseen ongelman, joka tapahtuu ennen kuin kenttää edes luetaan.

Miksi käynnistys voi juuttua

Aina päällä eston ollessa aktiivinen tarkoittaa, että VPN:n ulkopuolinen liikenne pudotetaan, mukaan lukien sen sovelluksen liikenne, joka omistaa VPN:n. Poistumistie on selvä: sovellus kutsuu protect()-toimintoa socketille, mikä sitoo sen taustaverkkoon, jolloin se ohittaa tunnelin ja päästetään ulos. Jokaisen VPN-asiakkaan on tehtävä tämä omalle siirrolleen, muuten se ei koskaan saavuttaisi palvelinta.

Kuvittele käyttöönotto, jossa ainoa päätepisteen nimen tunteva resolveri on itse tunnelin sisällä. Asiakas tarvitsee tunnelia nimen ratkaisemiseen ja nimeä tunnelin rakentamiseen. Se on todellinen kehämäinen riippuvuus, eikä mikään asiakkaan kokoonpano ratkaise sitä. Se on suunnitteluvirhe, ei ohjelmavirhe.

Aika paljastaa saman riippuvuuden lievemmissä muodoissa. Käynnistyksen yhteydessä ennen ensimmäistä avausta laitteella ei ehkä ole vielä käyttökelpoista verkkoa; captive-portaalissa verkko on olemassa mutta estää kaiken paitsi portaalin; siirryttäessä Wi-Fi:stä matkapuhelinverkkoon suojatun socketin taustaverkko muuttuu ja asiakkaan on huomattava se ja ratkaistava uudelleen. Jokainen näistä on käynnistystapahtuma ja ansaitsee tarkoituksellisen testin sen sijaan, että se löydettäisiin kello 3 yöllä.

Miksi vastauksen kiinnittäminen ei ole korjaus

Kiusaus on ratkaista nimi kerran ja liittää saatu osoite numeeriseen kenttään tai kovakoodata se omaan koontiin. Se näyttää toimivan, ja se muuttaa nimen tilannekuvaksi. Kun operaattori siirtää päätepisteen, muuton, anycast-muutoksen tai uuden alueellisen osoitteen kautta, asiakas soittaa edelleen vanhaan eikä mikään käyttöliittymässä selitä miksi.

DNS-tietueilla on elinaika juuri siksi, että vastaukset voivat muuttua; välimuisti määritellään sen elinajan mukaan, ei ikuisesti. Vastauksen kiinnittäminen heittää pois mekanismin, joka tekee nimestä osoitetta paremman, samalla kun nimen käytön kustannus säilyy.

Kiinnittämiseen liittyy usein toinen huono tapa: identiteettitarkistusten löysääminen, koska yhteys epäonnistuu nyt toisin. Palvelimen identiteetin vahvistus ei ole osa käynnistysongelmaa, ja sen heikentäminen vaihtaa DNS-haitan sieppausriskiin.

Suunnitelmat, jotka kestävät uudelleenkäynnistyksen

Kestävä järjestely on vaatimaton. Käytä asiakasta, joka toteuttaa suojatut socketit oikein ja ratkaisee päätepisteensä taustaverkossa, ja anna sille päätepisteen nimi, joka ratkeaa julkisesti tai resolverin kautta, joka on tavoitettavissa ennen tunnelia. Jätä esto päälle; sen täysi poistaminen DNS:n toimimiseksi poistaa ominaisuuden, jonka vuoksi käyttöönotto on olemassa.

Missä päätepisteen on pysyttävä yksityisenä, tarjoa selkeä käynnistyspolku, jota alusta voi käyttää, kuten resolveri, joka on tavoitettavissa ilman tunnelia, tai operaattorin ylläpitämä hallintayhteys, ja pidä poikkeus kapeana ja käytännön omistamana käyttäjän kytkimen sijaan. Android VpnService -dokumentaatio on viite siitä, mitä alusta takaa suojauksesta ja elinkaaresta, ja VpnService.Builder-viite vahvistaa, että DNS-kenttä ottaa numeerisia osoitteita.

Tarkista sitten kolmessa vaiheessa, järjestyksessä, tuoreella yhteydellä uudelleenkäynnistyksen jälkeen: päätepisteen nimi ratkeaa, tunneli muodostetaan ja vertainen todentuu, ja yksityinen nimi ratkeaa tunnelin resolverin kautta. Jos ensimmäinen vaihe epäonnistuu, mikään myöhempi ei voi toimia.

• Päätepisteen ratkaisu tapahtuu sovelluksessa, tunnelin ulkopuolella, suojatulla socketilla.
• Rakentajan DNS-kenttä on tunnelin sisäisille sovelluksille, ei asiakkaan omalle päätepisteelle.
• Vain tunnelin kautta tavoitettava resolveri on umpikuja, ei hidas käynnistys.
• Testaa päätepiste, todennus ja yksityinen haku erikseen uudelleenkäynnistyksen jälkeen.