Waarom 'n wildcard in 'n OpenVPN-route-instruksie nie kan werk nie

route installeer adresvoorvoegsels, so 'n gasheernaam-patroon het niks om teen te pas nie. Gebruik 'n voorvoegsel vir netwerke en 'n proxy of PAC-lêer wanneer domeine die besluit moet neem.

Die bedoeling is redelik: stuur alles vir een maatskappydomein deur die tonnel en laat die res alleen. Die instruksie wat geredigeer word, installeer roetes, en 'n roete het geen begrip van 'n gasheernaam om teen te pas nie. Elke poging om 'n wildcard daarin te skryf, lewer of 'n ontledingsfout of, erger, 'n roete wat vandag toevallig werk omdat die naam na een adres opgelos het. Twee verskillende meganismes word gevra om mekaar se werk te doen.

Wat 'n roete installeer, en wat dit nooit lees nie

'n Roete-inskrywing sê dat 'n bestemmingsvoorvoegsel deur 'n koppelvlak bereikbaar is. Die kern pas pakkette teen daardie voorvoegsels aan, so die enigste identifiseerders wat betrokke is, is adresse en maskers. 'n Gasheernaam verskyn nooit in die aanstuur-besluit nie, en daarom kan 'n patroon nie daar gepas word nie.

OpenVPN kan 'n oplosbare naam in sommige roete-parameters aanvaar, en daardie verdraagsaamheid is 'n bron van verwarring. Die naam word opgelos terwyl die konfigurasie toegepas word, wat een of meer adresse lewer wat gewone roetes word. Daarna is die naam heeltemal uit die prentjie.

Dus is 'n roete wat uit 'n naam gebou is, 'n momentopname, nie 'n reël nie. Dit dek wat daardie naam op die oomblik wat die tonnel begin het, opgelos het, en dit is presies die gedrag wat jy nie wil hê vir 'n familie gashere wat verander nie. 'n Rekord wat môre skuif, laat die roete na gister wys.

Wanneer die bestemming werklik 'n voorvoegsel is

As die teiken 'n bekende privaatnetwerk is, skryf die voorvoegsel. Vir 'n dokumentasie-ruimte-voorbeeld lyk 'n enkele gasheer en 'n subnet soos volg:

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

Albei inskrywings noem adresse en maskers, en albei oorleef DNS-veranderings omdat niks daaraan van 'n naam afhang nie. Dit is die hele voordeel: die roete is 'n stelling oor topologie eerder as oor 'n opsoeking wat een keer gebeur het.

Moenie 'n groot voorvoegsel uit 'n enkele DNS-antwoord aflei nie. Een gasheernaam wat na een adres oplos, sê niks oor die grootte van die netwerk agter dit nie, en 'n geradene voorvoegsel is hoe 'n tonnel uiteindelik verkeer vasvang wat niemand bedoel het om deur te stuur nie. Vra die netwerkeienaar vir die werklike voorvoegsel in plaas daarvan om dit uit 'n opsoeking af te lei.

Wanneer die werkeenheid 'n gasheernaam is

Om volgens domein te kies, vereis iets wat die domein lees, wat 'n toepassingslaag-komponent beteken. Die gewone antwoord is 'n HTTP-proxy wat aan die oorkant van die tonnel woon, met die kliënt wat kies watter versoeke om daarheen te stuur.

'n Proxy-konfigurasielêer kan daardie keuse uitdruk. Die illustratiewe reëls hieronder stuur een domein en sy subdomeine na 'n proxy en alles anders direk:

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";
}

Die presiese-naam-vergeliking dek die domein self, en die agtervoegselvergeliking dek sy kinders sonder om 'n naam te pas wat bloot op soortgelyke karakters eindig. Albei is nodig, en as een weggelaat word, lewer dit 'n reël wat reg lyk en die top-domein of 'n bedrieër oorslaan.

Hierdie reëls kies 'n proxy; hulle skep nie een nie, en hulle verander geen bedryfstelsel-roete nie. Die proxy-adres het steeds sy eie pad deur die tonnel nodig, en versoeke wat as direk gemerk is, volg steeds watter roeteringsbeleid die masjien reeds het.

Wat die proxy-opsie nie dek nie

Programme wat die blaaier se proxy-konfigurasie ignoreer, word deur niks daarvan geraak nie. Opdragreël-gereedskap, opdateerders en toepassings met hul eie netwerkstapel neem die roetetabel, nie die PAC-lêer nie, so daardie gevalle benodig 'n ondersteunde per-toepassing-meganisme of 'n ander ontwerp. Inventariseer die kliënte wat saak maak voordat jy belowe dat die blaaierreël die werkvloei dek.

Om direk terug te keer is ook nie 'n ontsnappingsluik nie. As die masjien se roeteringsbeleid reeds alles in die tonnel stuur, bly 'n versoek wat as direk gemerk is, daarbinne, want die proxy-keuse en die roetetabel is verskillende besluite wat op verskillende lae geneem word.

Naamoplossing is 'n derde aparte vraag. Om te kies watter versoeke na 'n proxy gaan, sê niks oor watter oplosser hulle beantwoord nie, en om die twee as een instelling te behandel, lewer lekke wat onsigbaar is totdat iemand van buite af toets. Besluit waar elke navraag beantwoord word en skryf daardie besluit langs die proxy-reël neer. 'n Oplosser wat verander omdat die tonnel opgekom het, sal die antwoord stilweg verskuif.

Albei paaie toets, nie net die gelukkige een nie

Toets 'n gasheernaam wat behoort te pas, 'n gasheernaam wat nie behoort te pas nie, en die top-domein, aangesien die top-domein die geval is wat die meeste deur 'n slegs-agtervoegsel-reël gemis word. Bevestig dan watter pad elke versoek werklik geneem het eerder as om dit af te lei uit of die bladsy gelaai het.

Toets laastens die falingstak. 'n Proxy wat onbereikbaar is, behoort te faal op 'n manier wat jy vooraf besluit het, eerder as om stilweg terug te val na 'n direkte verbinding. Die network-options-verwysing dokumenteer die roete-parameters presies; die domeinhelfte van hierdie ontwerp lê heeltemal daarbuite.

Verwante artikels