Miten Apple VPN On Demand -domeenisäännöt käynnistävät tunnelin

Tunneli avautuu, kun pyydät yhtä sisäistä nimeä, ja pysyy kiinni, kun seuraava sovellus tarvitsee sitä yhtä kipeästi. Se ei ole sovelluksen bugi; se on domeenisäännön muoto. Applen on-demand-kokoonpano kuvaa yhteyden muodostamisen ehdot, ja näiden ehtojen domeenimuoto kysyy järjestelmän resolverilta kysymyksen ennen kuin yksikään paketti liikkuu. Kaksi kysymystä sekoitetaan jatkuvasti: milloin tunnelin pitäisi nousta ja mitä tunneli kuljettaa, kun se on olemassa. Ensimmäinen on laukaisin, toinen on reitti- ja resolverikäytäntö, ja yksi profiili asettaa yleensä molemmat samaan payloadiin, minkä vuoksi oikea domeenisääntö voi silti jättää sinut väärään verkkoon.

Laukaisin ja liikenteen valinta ovat eri kerroksissa

On-demand-sääntö elää VPN-payloadin on-demand-sanastossa: järjestetty luettelo säännöistä, joista jokaisella on toiminto ja joukko vastaavuusehtoja. Järjestelmä arvioi niitä, kun yhteys muuttuu tai kun jokin yrittää päästä verkkoon, ja toiminto päättää, nostetaanko tunneli, arvioidaanko se, katkaistaanko se vai jätetäänkö se huomiotta. Kaikki tämä tapahtuu alustan verkkokerroksessa ennen kuin sovelluksellasi on socket.

Seuraava on erillinen avainryhmä: tunnelin IPv4- ja IPv6-asetukset, sen sisällytetyt ja poissuljetut reitit, DNS-palvelimien osoitteet ja iOS:ssä ja iPadOS:ssa sovelluskohtainen kartoitus, joka päättää, mitkä sovellukset ylipäätään saavat käyttää tunnelia. Profiili voi yhdistää laajan laukaisimen kapeaan reittiin tai kapean laukaisimen oletusreittiin. Lue vain toinen puoli, niin toinen näyttää toimintahäiriöltä.

Minulla on laboratorioprofiili, joka yhdistyy aina, kun sisäisen domeenin alta pyydetään jotain, mutta reitittää tunneliin vain yhden /16:n. Se tekee täsmälleen sen, mitä sen payload sanoo, ja se on myös sellainen profiili, joka tuottaa tikettejä: ihmiset olettavat, että yhdistetty tunneli tarkoittaa, että heidän liikenteensä on sen sisällä.

Mitä domeenisääntö todella kysyy resolverilta

Säännön domeenimuoto, jota usein kutsutaan nimellä connect-if-needed, ei tutki pakettien payloadia eikä tarkkaile URL-osoitteita. Kun nimi ratkaistaan, järjestelmä vertaa sitä säännön domeeneihin ja kysyy osuman kohdalla, voidaanko nimi ratkaista tunnelin tarjoamien DNS-palvelimien kautta. Jos tunnelin resolver vastaa, nimi lasketaan sisäiseksi ja yhteys aloitetaan. Jos paikallinen resolver vastaa sen sijaan, nimi käsitellään ulkoisena eikä tunnelia ilmesty. Applen käyttöönoton yleiskatsaus kuvaa tätä verkon tunnistuksena ja sitä seuraavana yhteyden arviointina.

Siitä seuraa kaksi asiaa. Profiilin on nimettävä DNS-palvelimet tunnelin sisällä; domeenisäännöllä ilman tunnelin resolveria ei ole mitään vertailtavaa, joten arviointi ei voi tuottaa odotettua osumaa. Ja kyselyn on päästävä järjestelmän resolverille. Sovellus tai selain, joka ajaa omaa salattua DNS:ää, laajennus, joka vastaa paikallisesti, tai yhteys kirjaimelliseen osoitteeseen ei koskaan tuota sitä nimen ratkaisua, jota sääntö odotti. Yksi pisimmistä iltapäivistä, joita olen viettänyt, päättyi, kun huomasin, että tunnelin edessä oleva asiakas käytti DNS over HTTPS:ää.

Välimuisti poistaa myös laukaisimen. Jo välimuistissa olevaan nimeen voidaan vastata ilman koetusta, joka olisi käynnistänyt tunnelin, joten eilen toiminut sääntö epäonnistuu uudelleenkäynnistyksen jälkeen tai kun tunneli on ollut hetken pystyssä. macOS:ssä sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder nollaa tilan; iOS:ssä lentotilan vaihtaminen tai laitteen uudelleenkäynnistys antaa vastaavan puhtaan alun.

Osuman laajuus: nimet, sovellukset ja verkot

Domeeniosuma on yksi tyyppi useiden joukossa. Sääntö voi vastata myös liitäntätyyppiä (Wi-Fi, matkapuhelin, Ethernet) ja tiettyä SSID:tä, ja sovellus- tai Safari-domeenikohtaiset merkinnät sitovat tunnelin yhteen työnkulkuun. Tämä sidonta selittää oudon kokemuksen, jossa vain yksi sovellus käyttäytyy eri tavalla kuin kaikki muu: muut sovellukset ovat tunnelin laajuuden ulkopuolella, joten ne käyttävät edelleen paikallista polkua, vaikka tunnelikuvake sanoo yhdistetty.

Järjestys on tärkeämpi kuin ihmiset odottavat. Säännöt arvioidaan peräkkäin ja ensimmäinen osuma antaa toiminnon, joten kapean domeenisäännön yläpuolelle sijoitettu laaja yhdistä-mihin-tahansa-Wi-Fiin -sääntö voittaa hiljaa ja tekee domeenisäännöstä testaamattoman. Ennen kuin kirjoitat domeeniluettelon uudelleen, varmista, ettei mikään aiempi sääntö ole jo osunut.

Siksi always-on ei ole vain tiukempi on-demand-sääntö. Always-onin pakottaminen on erillinen käyttöönottotila, jolla on omat valvonta- ja hallintavaatimuksensa; se pitää tunnelin auki sen sijaan, että reagoisi nimeen. Jos tarvitset tunnelin, joka ei koskaan putoa, domeenisääntö on väärä työkalu.

Rikkoutunutta sääntöä jäljittelevät vikatilat

Useimmat ilmoitukset siitä, ettei domeenisääntö toimi, päätyvät yhteen viidestä paikasta, ja vain viimeinen niistä on säännön teksti.

Captive-portaalit ansaitsevat oman rivinsä, koska hotellien ja lentokenttien Wi-Fi sieppaa juuri sen kyselyn, josta sääntö riippuu. Kunnes portaali päästää laitteen sisään, tunnelin DNS-palvelin on tavoittamattomissa, koe epäonnistuu ja vika näyttää väärin kirjoitetulta domeenilta. Todennus on toinen hiljainen tapaus: sääntö voi laueta, tunneli voi alkaa yhdistää ja yhteys kuolee vanhentuneeseen varmenteeseen tai kehotteeseen, joka ilmestyy toiselle näytölle.

IPv6 luo muunnelman, joka on helppo diagnosoida väärin. Nimeen, jolla on molemmat osoiteperheet, voidaan vastata ensin AAAA-tietueesta, kun taas tunnelin reittiluettelo kuljettaa vain IPv4:ää. Yksi selain onnistuu, toinen epäonnistuu, ja domeeniluettelo on täysin syytön.

Testaa todellisella pyynnöllä tässä järjestyksessä

Lue käytäntö ennen kuin arvaat. macOS:ssä sudo profiles show -type configuration tulostaa asennetut profiilit, mukaan lukien VPN-payloadin, scutil --nc list näyttää palvelun tilan ja scutil --nc show <service> tulostaa on-demand-sanaston, jota järjestelmä käyttää. Hallinnoidussa iPhonessa tai iPadissa sama payload tulee hallintakonsolista tai MDM-raportista. Verkkolokit ovat saatavilla komennolla log stream --predicate 'subsystem == "com.apple.networkextension"' macOS:ssä ja laitekonsolin kautta, kun puhelin on liitettynä.

Testaa sitten isäntänimellä, jota ei ole kysytty aiemmin istunnossa. Valitse nimi tunnelin DNS-vyöhykkeeltä, jonka tiedät ratkeavan sisäisesti, pyydä sitä kerran ja katso, ilmestyykö tunneli. Suorita sama kysely kahdesti: toinen yritys käyttää välimuistipolkua, ja ero näiden välillä kertoo, onko laukaisin ratkaisu vai reititys.

Kun tunneli on pystyssä, tarkista kaksi kerrosta erikseen. netstat -rn -f inet ja netstat -rn -f inet6 näyttävät, mihin kukin etuliite osoittaa, scutil --dns näyttää resolverien järjestyksen ja sen, mikä liitäntä omistaa minkäkin resolverin, ja nettop -m route näyttää, mikä liitäntä kuljetti tavut. Jos tunneli on pystyssä ja resolver on oikein mutta resurssi epäonnistuu silti, lopeta säännön muokkaaminen; tarkista palvelinpuolen valtuutus ja paluureitti.

Kun sääntö kuuluu jollekulle toiselle

Jos tunneli ilmestyy uudelleen sen jälkeen, kun katkaisit sen, sääntö kuuluu yleensä profiilille eikä sovellukselle: MDM:n työntämä kokoonpano, jäljelle jäänyt henkilökohtainen profiili tai toisen asiakasohjelman asentama profiili. sudo profiles show -type configuration ja on-demand-avainten haku rajaa sitä, ja poistopolku on profiili, ei valikkorivin kytkin. Palvelumerkinnän tai sovelluksen poistaminen jättää säännön jälkeensä, ja seuraava asennus perii sen uudelleen.

Yksi testi ratkaisee omistajuuden: katkaise, odota, pyydä sisäinen nimi uudelleen. Jos tunneli palaa, laukaisin toimii suunnitellusti ja avoin kysymys on, kuka sitä hallinnoi ja onko se laajuus sitä, mitä haluat.

Ennen kuin kirjaat tämän bugiksi, käy läpi samat viisi tarkistusta: tunnelin resolveriosoitteet ovat payloadissa, nimi ei ollut välimuistissa, mikään aiempi sääntö ei osunut jo, reittiluettelo kattaa AAAA-polun ja sovellus on tunnelin laajuudessa. Kun kaikki viisi pitävät, sääntö tekee työnsä ja vika on kauempana polulla.