Verkkotunnuspohjainen VPN-reititys vai IP-reitit: kumpi sopii?

IP-reitti vastaa osoite-etuliitettä, ja ydin soveltaa sitä kysymättä lisäkysymyksiä. Verkkotunnuspohjainen VPN-sääntö vastaa nimeä, mikä tarkoittaa, että jonkin pinossa on päätettävä, mitä osoitteita nimi tällä hetkellä tarkoittaa, ja pidettävä päätös ajan tasalla. Nämä ovat erilaisia mekanismeja, joilla on erilaiset vikatilat, ja toimittajat käyttävät samaa sanaa molemmista. Niiden vertaaminen ominaisuusluetteloissa menee ohi aiheen; vertaa niitä sillä, mitä tapahtuu, kun vastaus muuttuu.

Hyödyllinen jako on säännön, joka ratkaisee, ja säännön, joka ei ratkaise, välillä.

Mihin kukin sääntö todella osuu

Etuliitesääntö osuu reititystaulun kohdeosoitteisiin. Mikään ei ratkea, mikään ei vanhene, ja osuma on tarkka jokaiselle paketille. Verkkotunnussääntö osuu sovelluksen nimeä koskevaan pyyntöön, jonka RFC 1034 määrittelee tunnisteiden puuksi eikä osoitteeksi. Jotkin tuotteet ratkaisevat nimen kerran ja asentavat tuloksena olevat osoitteet reiteiksi, mikä tekee säännöstä IP-säännön, johon on liitetty päivitysajastin.

Selvitä, kumpi näistä kahdesta sinulla on, ennen kuin alat vianetsintään, sillä vika näyttää kummassakin tapauksessa täysin erilaiselta.

Missä verkkotunnussääntö sijaitsee pinossa

Jos tuote toteuttaa verkkotunnussäännöt paikallisen välityspalvelimen kautta, liikenteen on päästävä siihen välityspalvelimeen, ja sovellukset, jotka jättävät järjestelmän välityspalvelimen huomiotta, ohittavat säännön kokonaan. Jos se toteuttaa ne ratkaisemalla nimiä ja lisäämällä reittejä, osoitteet ovat vain viimeisimmän päivityksen verran tuoreita. Jos se koukistaa ratkaisijan, DNS-käyttäytymisestä tulee osa reitityskäytäntöä, ja vararatkaisija voi hiljaa kumota sen.

Lue toimittajan malli, älä asetuksen merkintää. Kahdella asiakkaalla, joilla on Split Tunnel -niminen laatikko, voi olla kolme eri asiaa tekeillä.

Vertaa, mikä hajoaa

Kolme asiaa hajoaa eri tavoin. Osoitteiden vaihtuminen: CDN-isäntänimi voi ratketa eri osoitejoukkoon minuuteissa, joten kopioitu luettelo vanhenee huonosti. Aliverkkotunnusten laajuus: example.com-sääntö voi kattaa api.example.comin tai olla kattamatta, ja dokumentaatio on yleensä selkeä siitä, kumpi. Ratkaisun epäonnistuminen: kun ratkaisija epäonnistuu, ratkaiseva asiakas voi pudota liikenteen tunnelointiin tai sen lähettämiseen suoraan.

Vain toinen on kokoonpanokysymys. Kaksi muuta ovat suunnittelukysymyksiä siitä, kuinka paljon tuote on valmis arvaamaan.

Milloin etuliite on parempi vastaus

Vakaalle yksityiselle aliverkolle eksplisiittinen etuliite on selkeämpi, nopeampi ja helpompi auditoida. Se kestää myös ratkaisijan katkoksen, koska mitään ei tarvitse ratkaista. Turvaudu verkkotunnussääntöön, kun palvelu on isännöity, kun osoitteet vaihtuvat tai kun et todella voi luetella kohdejoukkoa. Älä turvaudu siihen vain siksi, että isäntänimi on se, minkä satut tietämään.

Arvattu staattinen luettelo on molempien huonoin: se näyttää ylläpidetyltä ja jättää hiljaa liikenteen väliin sinä päivänä, kun palveluntarjoaja lisää isännän.

Vahvista tuoreella pyynnöllä

Testaa kylmällä pyynnöllä normaalin uudelleenyhdistämisen jälkeen, koska välimuistiin tallennettu sivu ei ehkä koskaan osu sääntöön. Ratkaise nimi ja tarkista sitten, mihin yhteys todella meni. dig +short app.example.com antaa nykyisen osoitejoukon, ja asiakkaan yhteysluettelo kertoo, mikä liitäntä kuljetti virran.

Toista tuotteen dokumentoiman päivitysvälin jälkeen. Jos osoitejoukko siirtyy eikä sääntö seuraa, olet löytänyt todellisen käyttäytymisen.

Pidä myös ratkaisijakäytäntö erillään. Verkkotunnussääntö tarvitsee oikeat nimitiedot, mutta ei itsessään päätä, mikä ratkaisija vastaa kyselyyn.