Miten jaettu tunneli päättää, mikä liikenne käyttää VPN:ää

Jaettu tunneli on sääntöjoukkona ilmaistu reitityspolitiikka, ja asiakasohjelma on vain se, joka asentaa ne. Erottelu tapahtuu kahdessa paikassa: yhdistävät säännöt, jotka valitsevat jokaiselle paketille polun, ja sidonnat, jotka pitävät sovelluksen yhdellä liittymällä, mitä taulukko sanoo. Mihin mekanismiin asiakkaasi tukeutuu, selittää useimmat ihmisten raportoimat yllätykset.

Politiikka, jonka voit ilmaista yhdellä rivillä, on testattavissa. Nopeampana selailuna kuvattu politiikka ei ole, eikä se kerro, mitä sääntöä muuttaa, kun pyyntö kulkee väärään suuntaan.

Asiakas asentaa säännöt, ydin tekee valinnan

Kun tunneli nousee, asiakas lisää reitit ja usein politiikkasäännöt samaan taulukkoon, jota muut liittymäsi käyttävät. Jokainen paketti saapuu sitten hakuun, joka vertaa kohdettaan jokaiseen ehdokasetuliitteeseen ja pitää täsmällisimmän vastineen, kun taas prioriteetti ratkaisee eri taulukoihin osoittavien sääntöjen väliset tasapelit. Mikään siinä haussa ei tiedä, että paketti tuli selaimen välilehdestä eikä varmuuskopiointityöstä. Voittava sääntö on se, joka asettaa polun, ja voit lukea sen ennen muutosta ja sen jälkeen.

Siksi jaettu tunneli voi tuntua mielivaltaiselta. Kaksi kohdetta samassa sovelluksessa voivat kulkea eri polkuja vain siksi, että toinen etuliite on toista kapeampi.

Sama valinta on jokaisella alustalla, vaikka nimet muuttuvat. Windows työntää päätöksen suodatinalustalleen, Android paljastaa sovelluskohtaisen sallittujen luettelon VPN-palvelunsa kautta ja macOS kiinnittää tunnelin laitteeseen, joka yhä tottelee reititystaulukkoa. Microsoftin reititysmuistiinpanot kannattaa lukea Windowsin tapauksessa, ja yhdelle alustalle kirjoitettu opas siirtyy harvoin muuttumattomana toiselle.

Sovelluskohtainen sidonta ja kohde-etuliitteet ovat eri työkaluja

Kohdepolitiikka kysyy, minne paketti menee, ja neuvottelee reititystaulukon tai politiikkasäännön kanssa. Sovelluskohtainen politiikka kysyy, mikä ohjelma avasi pistokkeen, ja alusta pitää sen ohjelman tunnelin liittymällä, vaikka tarkempi reitti osoittaisi muualle. Toinen on vahvempi, koska se selviää taulukkomuutoksista, mutta se kattaa vain prosessit, jotka alusta voi osoittaa. Apuprosessi, upotettu selain tai palvelu, joka avaa oman yhteytensä, ei välttämättä peri sidontaa, jota oletit.

Kumpikaan lähestymistapa ei selviä nimipohjaisesta politiikasta ilman apua. Suurten sivustojen osoitteet pyörivät sisältöverkkojen välillä, joten isäntänimen naulaaminen muutamaan etuliitteeseen tuottaa säännön, joka hiljaa lakkaa täsmäämästä. Politiikka, jonka on seurattava nimiä, tarvitsee resolverin huomioivan komponentin staattisen reitin sijaan.

DNS ja turvakytkin noudattavat omia sääntöjään

Nimien ratkaisu on erillinen päätös pakettien reitityksestä, ja jaettu tunneli haluaa yleensä kaksi resolveria: yrityksen sisäisille nimille, paikallisen kaikelle muulle. Asiakas voi asentaa liittymäkohtaiset DNS-asetukset, antaa kyselyt välittävälle resolverille tai jättää järjestelmän oletuksen koskemattomaksi. Selain, jolla on oma salattu resolveri, ohittaa kaikki kolme järjestelyä. Testaa kysely sen sijaan, että oletat resolverin seuranneen reittiä.

Turvakytkin lisää suodattimen päälle, eikä se suodatin aina erota aiottua poikkeusta vahingossa tapahtuneesta vuodosta. Jotkin asiakkaat estävät kaiken tunnelin ulkopuolella, kun taas toiset sallivat politiikan ilmoittamat poikkeukset, joten lue, mitä käyttäytymistä omasi toteuttaa, ennen kuin luotat kumpaankaan.

Tarkista jakautuminen molemmilta puolilta

Testaa sisällytetty polku ja poissuljettu polku erikseen ja arvioi tulos liittymän nimen, älä julkisen osoitteen perusteella. Nämä komennot olettavat Linux-isäntää, jonka tunnelilaite on jo ylhäällä. Korvaa 203.0.113.10 kohteella, johon politiikkasi reitittää sisään, ja 198.51.100.25 kohteella, jonka se lähettää ulos.

ip route get 203.0.113.10
ip route get 198.51.100.25
resolvectl query intranet.example.com
curl -s --interface tun0 https://example.com -o /dev/null -w '%{http_code}\n'

Lue kaksi ensimmäistä vastausta yhdessä, koska kummassakin nimetty liittymä näyttää, asettiko jakautuminen kyseisen kohteen tunneliin. Resolverin kysely näyttää, mikä palvelin vastasi sisäiseen nimeen, ja viimeinen komento todistaa, että tunnelilaite ylipäätään pystyy kuljettamaan pyynnön. Epäonnistuminen toisella rivillä, kun ensimmäinen onnistuu, tarkoittaa, että politiikka tekee täsmälleen sen, mitä sille sanottiin.

Toista joukko uudelleenyhdistämisen jälkeen ja verkkomuutoksen jälkeen. Vuokrasopimuksen uusiminen ja liittymien vaihtelu ovat niitä kohtia, joissa jakautuminen lakkaa vastaamasta tarkoitusta, jota varten se rakennettiin, ja jokaisen ajon tallennettu tuloste tekee ajautumisen ilmeiseksi.