Miks metamärk OpenVPN-i marsruudidirektiivis ei saa toimida

marsruut paigaldab aadressi eesliited, seega hostinime mustril pole millegagi sobida. Kasutage võrkude jaoks eesliidet ning puhverserverit või PAC-faili, kui domeenid peavad otsustama.

Kavatsus on mõistlik: saata ühe ettevõtte domeeni jaoks kõik tunnelisse ja jätta ülejäänu rahule. Redigeeritav direktiiv paigaldab marsruute ja marsruudil pole mingit hostinime mõistet, millega sobida. Iga katse sinna metamärk kirjutada annab kas parsimisvea või, mis hullem, marsruudi, mis täna juhuslikult töötab, sest nimi lahendati üheks aadressiks. Kahel erineval mehhanismil palutakse teineteise tööd teha.

Mida marsruut paigaldab ja mida ta kunagi ei loe

Marsruudikirje ütleb, et sihtkoha eesliide on liidese kaudu kättesaadav. Kernel sobitab pakette nende eesliidetega, seega on ainsad kaasatud identifikaatorid aadressid ja maskid. Hostinimi ei esine kunagi edastusotsuses ja seetõttu ei saa seal mustrit sobitada.

OpenVPN võib mõnes marsruudiparameetris vastu võtta lahendatava nime ja see tolerantsus on segaduse allikas. Nimi lahendatakse konfiguratsiooni rakendamise ajal, luues ühe või mitu aadressi, millest saavad tavalised marsruudid. Pärast seda on nimi pildilt täielikult kadunud.

Nii et nimest ehitatud marsruut on hetktõmmis, mitte reegel. See katab seda, milleks see nimi tunneli käivitumise hetkel lahendati, ja see on täpselt see käitumine, mida te muutuva hostide pere jaoks ei soovi. Kirje, mis homme liigub, jätab marsruudi eilsele osutama.

Kui sihtkoht on tõesti eesliide

Kui sihtmärk on teadaolev privaatvõrk, kirjutage eesliide. Dokumentatsiooniruumi näite jaoks näevad üks host ja üks alamvõrk välja nii:

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

Mõlemad kirjed nimetavad aadresse ja maske ning mõlemad peavad DNS-i muutustele vastu, sest miski nende juures ei sõltu nimest. See on kogu eelis: marsruut on väide topoloogia kohta, mitte otsingu kohta, mis toimus korra.

Ärge tuletage suurt eesliidet ühest DNS-vastusest. Üks hostinimi, mis lahendub üheks aadressiks, ei ütle teile midagi selle taga oleva võrgu suuruse kohta ja oletatud eesliide on viis, kuidas tunnel hakkab lõpuks püüdma liiklust, mida keegi ei kavatsenud sellest läbi saata. Küsige võrgu omanikult tegelikku eesliidet, selle asemel et seda otsingust tuletada.

Kui tööühik on hostinimi

Domeeni järgi valimine nõuab midagi, mis domeeni loeb, see tähendab rakenduskihi komponenti. Tavaline vastus on HTTP-puhverserver, mis asub tunneli teisel poolel, kusjuures klient valib, millised päringud sellele saata.

Puhverserveri konfiguratsioonifail saab seda valikut väljendada. Allolevad näidisreeglid saadavad ühe domeeni ja selle alamdomeenid puhverserverile ning kõik muu otse:

function FindProxyForURL(url, host) {
    var h = host.toLowerCase();
    if (h === "corp.example" || dnsDomainIs(h, ".corp.example")) {
        return "PROXY 10.60.0.12:3128";
    }
    return "DIRECT";
}

Täpse nime võrdlus katab domeeni enda ja sufiksi võrdlus katab selle lapsed, ilma et sobiks nimi, mis lihtsalt lõpeb sarnaste tähtedega. Mõlemat on vaja ja ühe ärajätmine annab reegli, mis näib õige ja jätab vahele tipu või petise.

Need reeglid valivad puhverserveri; need ei loo seda ega muuda ühtegi operatsioonisüsteemi marsruuti. Puhverserveri aadress vajab endiselt oma teed läbi tunneli ja otsesteks märgitud päringud järgivad endiselt seda marsruutimispoliitikat, mis masinal juba on.

Mida puhverserveri valik ei kata

Programmid, mis ignoreerivad brauseri puhverserveri konfiguratsiooni, ei puutu sellest üldse. Käsurea tööriistad, uuendajad ja oma võrgupinuga rakendused võtavad marsruuditabeli, mitte PAC-faili, seega need juhtumid vajavad toetatud rakendusepõhist mehhanismi või teistsugust disaini. Loetlege kliendid, mis loevad, enne kui lubate, et brauserireegel katab töövoo.

Otse tagasi minek pole samuti pääsetee. Kui masina marsruutimispoliitika saadab juba kõik tunnelisse, jääb otsesteks märgitud päring selle sees, sest puhverserveri valik ja marsruuditabel on erinevad otsused, mis tehakse erinevatel kihtidel.

Nimede lahendamine on kolmas eraldi küsimus. Valik, millised päringud puhverserverile lähevad, ei ütle midagi selle kohta, milline lahendaja neile vastab, ja kahe kohtlemine ühe seadena tekitab lekkeid, mis on nähtamatud seni, kuni keegi väljastpoolt testib. Otsustage, kus iga päringule vastatakse, ja kirjutage see otsus puhverserveri reegli kõrvale. Lahendaja, mis muutub seetõttu, et tunnel tõusis, liigutab vastust vaikselt.

Mõlema tee testimine, mitte ainult õnneliku

Testige hostinime, mis peaks sobima, hostinime, mis ei peaks, ja domeeni tippu, sest tipp on juhtum, mille ainult sufiksireegel kõige sagedamini vahele jätab. Seejärel kinnitage, millise tee iga päring tegelikult läks, selle asemel et seda lehe laadimisest tuletada.

Lõpuks testige tõrkekatet. Puhverserver, mis pole kättesaadav, peaks ebaõnnestuma viisil, mille olete eelnevalt otsustanud, selle asemel et vaikselt otseühendusele tagasi langeda. Võrguvalikute viide dokumenteerib marsruudiparameetrid täpselt; selle disaini domeenipool asub täielikult sellest väljas.

Seotud artiklid