Domeenipõhine VPN-marsruutimine versus IP-marsruudid: milline sobib?

IP-marsruut vastab aadressi prefiksile ja kernel rakendab seda ilma täiendavaid küsimusi esitamata. Domeenipõhine VPN-reegel vastab nimele, mis tähendab, et miski pinu sees peab otsustama, milliseid aadresse see nimi praegu tähendab, ja hoidma seda otsust värskena. Need on erinevad mehhanismid erinevate rikkerežiimidega ning tarnijad kasutavad mõlema kohta sama sõna. Nende võrdlemine funktsioonide loendites tabab vale kohta; võrrelge neid selle järgi, mis juhtub, kui vastus muutub.

Kasulik eraldus on reegli vahel, mis lahendab, ja reegli vahel, mis ei lahenda.

Millega kumbki reegel tegelikult vastab

Prefiksireegel vastab sihtaadressidele marsruutimistabelis. Miski ei lahendu, miski ei aegu ja vaste on iga paketi jaoks täpne. Domeenireegel vastab rakenduse nõudele nime järele, mille RFC 1034 määratleb siltide puuna, mitte aadressina. Mõned tooted lahendavad nime üks kord ja paigaldavad tulemuseks saadud aadressid marsruutidena, mis muudab reegli IP-reegliks, millele on lisatud värskendustaimer.

Enne silumist tehke kindlaks, kumb neist kahest teil on, sest rike näeb kummagi puhul täiesti erinev välja.

Kus domeenireegel pinus asub

Kui toode rakendab domeenireegleid kohaliku puhverserveri kaudu, peab liiklus selle puhverserverini jõudma, ja rakendused, mis süsteemset puhverserverit eiravad, mööduvad reeglist täielikult. Kui see rakendab neid nimesid lahendades ja marsruute lisades, on aadressid värsked vaid viimase värskenduseni. Kui see haagib lahendaja, muutub DNS-i käitumine marsruutimispoliitika osaks ja varulahendaja võib selle vaikselt tühistada.

Lugege tarnija mudelit, mitte seade silti. Kaks klienti, kellel on kast nimega Split Tunnel, võivad teha kolme erinevat asja.

Võrrelge, mis katki läheb

Kolm asja lähevad katki erinevalt. Aadresside muutumine: CDN-i hostinimi võib mõne minuti jooksul lahenduda teiseks aadresside kogumiks, seega kopeeritud loend vananeb halvasti. Alamdomeenide ulatus: reegel example.com-i jaoks võib api.example.com-i katta või mitte, ja dokumentatsioon on tavaliselt selgesõnaline, kumb juhtum kehtib. Lahendamise rike: kui lahendaja ei tööta, võib lahendav klient langeda tagasi liikluse tunnelimisele või selle otse saatmisele.

Ainult teine on konfiguratsiooniküsimus. Ülejäänud kaks on disainiküsimused selle kohta, kui palju toode on valmis oletama.

Millal on prefiks parem vastus

Stabiilse privaatse alavõrgu jaoks on selgesõnaline prefiks selgem, kiirem ja kergemini auditeeritav. See elab üle ka lahendaja katkestuse, sest midagi ei pea lahendama. Kasutage domeenireeglit siis, kui teenust majutatakse, kui aadressid pöörlevad või kui te tõesti ei suuda sihtkogumit loetleda. Ärge kasutage seda ainult sellepärast, et hostinimi on see, mida te juhuslikult teate.

Oletatud staatiline loend on mõlemast halvim: see näeb hooldatud välja ja jätab vaikselt liikluse vahele päeval, mil teenusepakkuja lisab hosti.

Kontrollige värske päringuga

Testige külma päringuga pärast tavalist uuesti ühendamist, sest vahemällu salvestatud leht ei pruugi reeglit kunagi puudutada. Lahendage nimi, seejärel kontrollige, kuhu ühendus tegelikult läks. dig +short app.example.com annab praeguse aadressikogumi ja kliendi ühenduste loend näitab, milline liides voogu kandis.

Korrake pärast värskendusintervalli, mille toode dokumenteerib. Kui aadressikogum triivib ja reegel ei järgne, olete leidnud tegeliku käitumise.

Hoidke ka lahendaja poliitika eraldi. Domeenireegel vajab õigeid nimeandmeid, kuid ei otsusta iseenesest, milline lahendaja päringule vastab.