Split-tunnel-dokumentaatio tarvitsee DNS-säännön jokaisen reitin viereen
Reitti päättää osoitteen mukaan, resolver päättää nimen mukaan. Dokumentoi molemmat valitsimet jokaista virtaa kohden, kumpikin yhdellä testillä, muuten muistiinpano epäonnistuu, kun DNS siirtyy.
Split-tunnel-muistiinpano, joka sanoo "toimistoliikenne kulkee VPN:n kautta", on dokumentoinut yhden päätöksen ja vihjannut kolmeen muuhun. Pakettikerroksessa reititystaulu valitsee liitännän kohdeosoitteen perusteella; nimikerroksessa resolver valitsee palvelimen kyselyn perusteella, ja nämä kaksi valintaa tehdään toisistaan riippumatta. Siksi oikein dokumentoitu etuliite voi silti tuottaa koneen, joka ratkaisee sisäisen nimen julkiseksi osoitteeksi tai ei ratkaise mitään, kun reitti näyttää täydelliseltä.
Kaksi valitsinta, yksi yhteysyritys
Kun sovellus muodostaa yhteyden osoitteeseen files.corp.example, kaksi hakua tapahtuu ennen kuin paketti on olemassa. Resolver päättää, mikä palvelin saa kyselyn, käyttäen hakuverkkoalueita, linkkikohtaisia reititysverkkoalueita tai profiilin nimenomaista sääntöä. Reititystaulu päättää sitten, minne tuloksena oleva osoite menee, käyttäen pisintä etuliiteosumaa kohteeseen.
Mikään ei yhdistä näitä kahta päätöstä. Yksityinen vyöhyke voi vastata osoitteella 10.20.4.11, kun reititystaulu lähettää 10.20.0.0/16 tunneliin, ja yhteys toimii. Käännä kumpi tahansa ja se epäonnistuu tavalla, joka näyttää toiselta: oikea DNS-käytäntö ja puuttuva reitti antavat ratkaistun nimen ja aikakatkaisun, kun taas oikea reitti ja julkinen resolver antavat osoitteen, joka reitittyy puhtaasti väärään paikkaan.
Split-horizon DNS tekee tästä terävämpää. Sama nimi voi palauttaa yksityisen osoitteen sisäiseltä resolverilta ja julkisen osoitteen internetiin päin kääntyneeltä, joten muistiinpano, joka tallentaa vain etuliitteen, ei voi ennustaa, mitä osoitetta asiakas todella käyttää. Kirjoita resolverin polku muistiin, muuten osoite on arvaus.
Mitä vain reitistä kertova muistiinpano jättää pois
Vain reitistä kertova tietue on hyödytön split-tunnelin yleisimmälle vialle: nimet. Käyttäjä ilmoittaa, että intranet ei lataudu, tunneli on ylhäällä ja etuliite on läsnä. Lipun ottavalla ei ole tietuetta siitä, minkä resolverin olisi pitänyt vastata, ei tapaa erottaa väärää hakuliitettä estetystä palvelimesta eikä vertailupohjaa.
Toinen puute on poikkeusluettelo. Split-tunnel-suunnittelun määrittää yhtä paljon se, mikä jää tunnelin ulkopuolelle, kuin se, mikä sinne tulee, ja pois jätetyt alueet ovat yleensä niitä, jotka rikkoutuvat ensin, koska tarkempi paikallinen reitti tai asiakaspuolen suodatin voi kumota aikomuksen profiilia koskettamatta.
Kolmas on tunnelin kaukainen puoli. Asiakkaan reitti laittaa paketin vain johdolle; yhdyskäytävän on silti välitettävä se ja oltava paluupolku. strongSwanin välitysohje muistuttaa, että yhdyskäytävän välitys- ja palomuurisäännöt ovat osa ominaisuutta, eivät osa putkitöitä, joita voi pitää itsestäänselvyytenä.
Kentät, jotka tekevät muistiinpanosta toteutettavan
Yksi rivi virtaa kohden, ja virta on kohde plus nimi plus omistaja. Nämä ovat kentät, jotka selviävät todellisen tapahtuman kohtaamisesta:
| Field | Why it has to be written down |
|---|---|
| Destination prefix and address family | The route is per family; an IPv4 note says nothing about a AAAA answer |
| Selected tunnel or direct path | Names the decision, not the symptom |
| Private namespace and resolver | Which domain, which server, which search suffix |
| Public name path | Confirms public names do not accidentally use the private resolver |
| Where the rule lives | Client profile, server push, OS policy or management tool |
| Owner and review date | Namespaces change owner more often than routes change |
Rivi "missä se asuu" on se, jonka ihmiset ohittavat. Palvelimen työntämä etuliite, asiakasprofiilin lisäämä reitti ja komentotulkkiin kirjoitettu reitti eroavat siinä, kuka voi muuttaa niitä ja selviävätkö ne uudelleenyhdistämisestä. Ilman tätä kenttää seuraava insinööri ei voi sanoa, kumpaa kolmesta hän katsoo.
Yksi testi sääntöä kohden, ei yhtä tunnelia kohden
Jokainen rivi tarvitsee kaksi vaaratonta tarkistusta: yksi, joka harjoittaa reittiä, ja yksi, joka harjoittaa nimeä. Reitille pyydä jotain, jonka on ylitettävä tunneli, ja vahvista polku eikä tavoitettavuus, esimerkiksi tracert -d 10.20.4.11 Windowsissa tai ip route get 10.20.4.11 Linuxissa. Nimelle kysy yksityinen nimi ja kirjaa, mikä palvelin vastasi, käyttäen resolvectl query files.corp.example tai dig files.corp.example muistiinpanon nimeämää resolveria vastaan.
Lisää myös negatiivinen odotus: mitä pitäisi tapahtua, kun tunneli on alhaalla. Poissuljetulla sovelluksella Android- tai iOS-laitteessa, jossa VPN:ittömän eston asetus on päällä, ei ehkä ole lainkaan yhteyttä, ja työpöytäasiakas voi jättää saman sovelluksen toimimaan, kun tunneli yhdistää uudelleen. Aiottu vastaus kirjaamalla "VPN rikkoi sovellukseni" muuttuu tarkistettavaksi väitteeksi.
Säilytä tietue kokoonpanon yhteydessä
Tallenna muistiinpano sen kuvaaman profiilin viereen ja versioi se kyseisen profiilin kanssa. Wikissä oleva asiakirja, jota kukaan ei päivitä, on huhu; taulukko samassa repositoriossa työnnettyjen reittien ja resolver-käytännön kanssa voidaan tarkistaa samassa muutoksessa.
Kun jotain hajoaa, vertaa käytössä olevaa reittiä ja tehollista resolveria tietueeseen ennen kuin lisäät uuden poikkeuksen. Kaksi kolmesta yleisestä syystä — vanha nimiavaruussääntö ja sovelluskäytännön ulkopuolinen apuprosessi — näyttävät täsmälleen VPN-vialta ja ovat näkymättömiä, jos muistiinpano luettelee vain etuliitteet.
Ennen kuin kutsut muistiinpanon valmiiksi, vahvista, että se vastaa kirjallisesti näihin: mikä etuliite, mille osoiteperheelle; mikä yksityinen nimiavaruus, minkä resolverin vastaamana; mitkä nimet pysyvät tarkoituksella julkisina; missä kukin sääntö on määritetty ja kuka sen omistaa; sekä yksi komento, joka todistaa reitin, ja yksi, joka todistaa nimen. Jos jokin näistä puuttuu, seuraava tapahtuma diagnosoidaan tyhjästä.