Uz domēnu balstīta VPN maršrutēšana pret IP maršrutiem: kurš ir piemērots?

IP maršruts atbilst adreses prefiksam, un kodols to piemēro, neuzdodot vairāk jautājumu. Uz domēnu balstīts VPN noteikums atbilst nosaukumam, kas nozīmē, ka kaut kam stekā ir jāizlemj, kādas adreses šis nosaukums pašlaik apzīmē, un šis lēmums jāuztur aktuāls. Tie ir dažādi mehānismi ar dažādiem atteices režīmiem, un piegādātāji abiem lieto vienu un to pašu vārdu. To salīdzināšana funkciju sarakstos palaiž garām būtību; salīdziniet tos pēc tā, kas notiek, kad atbilde mainās.

Noderīgā atdalīšana ir starp noteikumu, kas atrisina, un noteikumu, kas to nedara.

Kam patiesībā atbilst katrs noteikums

Prefiksa noteikums atbilst galamērķa adresēm maršrutošanas tabulā. Nekas netiek atrisināts, nekas nebeidzas, un atbilstība ir precīza katram paketei. Domēna noteikums atbilst lietotnes pieprasījumam pēc nosaukuma, ko RFC 1034 definē kā etiķešu koku, nevis adresi. Daži produkti nosaukumu atrisina vienreiz un iegūtās adreses instalē kā maršrutus, kas noteikumu padara par IP noteikumu ar pievienotu atjaunināšanas taimeri.

Pirms atkļūdošanas noskaidrojiet, kurš no šiem diviem jums ir, jo atteice katrā gadījumā izskatās pilnīgi citādi.

Kur domēna noteikums atrodas stekā

Ja produkts domēna noteikumus īsteno ar vietējo starpniekserveri, trafikam jāsasniedz šis starpniekserveris, un lietotnes, kas ignorē sistēmas starpniekserveri, noteikumu pilnībā apiet. Ja tas tos īsteno, atrisinot nosaukumus un pievienojot maršrutus, adreses ir tik svaigas, cik pēdējā atjaunināšana. Ja tas piekabina atrisinātāju, DNS uzvedība kļūst par maršrutošanas politikas daļu, un rezerves atrisinātājs to var klusi atcelt.

Lasiet piegādātāja modeli, nevis iestatījuma etiķeti. Divi klienti ar lauku nosaukumā Split Tunnel var darīt trīs dažādas lietas.

Salīdziniet, kas lūzt

Trīs lietas lūzt atšķirīgi. Adrešu mainība: CDN resursdatora nosaukums dažu minūšu laikā var atrisināties uz citu adrešu kopu, tāpēc nokopēts saraksts ātri noveco. Apakšdomēnu tvērums: noteikums example.com var aptvert api.example.com vai arī ne, un dokumentācija parasti skaidri norāda, kurš gadījums ir spēkā. Atrisināšanas kļūme: kad atrisinātājs sabrūk, atrisinošais klients var pāriet uz trafika tunelēšanu vai tā tiešu sūtīšanu.

Tikai otrais ir konfigurācijas jautājums. Pārējie divi ir dizaina jautājumi par to, cik daudz produkts ir gatavs minēt.

Kad prefikss ir labākā atbilde

Stabilam privātam apakštīklam skaidrs prefikss ir saprotamāks, ātrāks un vieglāk auditējams. Tas arī pārdzīvo atrisinātāja kļūmi, jo nekas nav jāatrisina. Izvēlieties domēna noteikumu, kad pakalpojums tiek mitināts, kad adreses rotē vai kad jūs tiešām nevarat uzskaitīt galamērķu kopu. Neizvēlieties to tikai tāpēc, ka resursdatora nosaukums ir tas, ko jūs nejauši zināt.

Minēts statisks saraksts ir sliktākais no abiem: tas izskatās uzturēts un klusi palaiž garām trafiku tajā dienā, kad pakalpojumu sniedzējs pievieno resursdatoru.

Pārbaudiet ar svaigu pieprasījumu

Pārbaudiet ar aukstu pieprasījumu pēc parastas atkārtotas savienošanas, jo kešatmiņā saglabāta lapa var nekad nepieskarties noteikumam. Atrisiniet nosaukumu, pēc tam pārbaudiet, kur savienojums patiešām aizgāja. dig +short app.example.com sniedz pašreizējo adrešu kopu, un klienta savienojumu saraksts parāda, kura saskarne nesa plūsmu.

Atkārtojiet pēc produkta dokumentētā atjaunināšanas intervāla. Ja adrešu kopa novirzās un noteikums tai neseko, jūs esat atradis īsto uzvedību.

Turiet atsevišķi arī atrisinātāja politiku. Domēna noteikumam ir vajadzīgi pareizi nosaukumu dati, taču tas pats par sevi neizlemj, kurš atrisinātājs atbild uz vaicājumu.