Zakaj nadomestni znak v direktivi route OpenVPN ne more delovati
pot namesti prefikse naslovov, zato vzorec imena gostitelja nima s čim primerjati. Za omrežja uporabite prefiks, kadar pa morajo odločati domene, proxy ali datoteko PAC.
Namen je smiseln: poslati vse za eno domensko podjetje skozi tunel in ostalo pustiti pri miru. Direktiva, ki se ureja, namešča poti, pot pa nima nobenega pojma imena gostitelja, s katerim bi se lahko primerjala. Vsak poskus, da bi vanjo zapisali nadomestni znak, da bodisi napako razčlenjevanja bodisi, kar je slabše, pot, ki danes deluje naključno, ker se je ime razrešilo na en naslov. Dva različna mehanizma sta prošena, da opravljata delo drug drugega.
Kaj pot namesti in česa nikoli ne prebere
Vnos poti pravi, da je ciljni prefiks dosegljiv prek vmesnika. Jedro primerja pakete s temi prefiksi, zato so edini vpleteni identifikatorji naslovi in maske. Ime gostitelja se nikoli ne pojavi v odločitvi o posredovanju, zato tam vzorca ni mogoče primerjati.
OpenVPN lahko v nekaterih parametrih poti sprejme razrešljivo ime, in ta strpnost je vir zmede. Ime se razreši med uporabo konfiguracije, kar ustvari enega ali več naslovov, ki postanejo običajne poti. Po tem ime popolnoma izgine s slike.
Torej je pot, zgrajena iz imena, posnetek, ne pravilo. Pokriva tisto, na kar se je to ime razrešilo v trenutku, ko se je tunel začel, in to je natanko vedenje, ki ga ne želite za družino gostiteljev, ki se spreminja. Zapis, ki se bo jutri premaknil, pusti pot, ki kaže na včeraj.
Ko je cilj resnično prefiks
Če je cilj znano zasebno omrežje, napišite prefiks. Za primer iz dokumentacijskega prostora sta en gostitelj in eno podomrežje videti takole:
route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0
Oba vnosa navajata naslove in maske, in oba preživita spremembe DNS, ker nič v njima ni odvisno od imena. To je vsa prednost: pot je trditev o topologiji in ne o iskanju, ki se je zgodilo enkrat.
Ne izpeljite velikega prefiksa iz enega samega odgovora DNS. Eno ime gostitelja, razrešeno na en naslov, vam ne pove ničesar o velikosti omrežja za njim, in ugiban prefiks je način, kako tunel na koncu zajame promet, ki ga nihče ni nameraval poslati skozenj. Vprašajte lastnika omrežja za dejanski prefiks, namesto da bi ga izpeljali iz iskanja.
Ko je delovna enota ime gostitelja
Izbiranje po domeni zahteva nekaj, kar domeno bere, torej komponento aplikacijske plasti. Običajen odgovor je proxy HTTP, ki živi na drugi strani tunela, odjemalec pa izbira, katere zahteve mu pošlje.
Konfiguracijska datoteka proxyja lahko izrazi to izbiro. Spodnja ilustrativna pravila pošljejo eno domeno in njene poddomene na proxy, vse drugo pa neposredno:
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";
}
Primerjava točnega imena pokriva samo domeno, primerjava pripone pa njene otroke, ne da bi se ujemala z imenom, ki se le konča s podobnimi znaki. Obe sta potrebni, in če eno izpustite, dobite pravilo, ki je videti pravilno in preskoči vrh ali prevaranta.
Ta pravila izberejo proxy; ne ustvarijo ga in ne spremenijo nobene poti operacijskega sistema. Naslov proxyja še vedno potrebuje svojo pot skozi tunel, zahteve, označene kot neposredne, pa še vedno sledijo politiki usmerjanja, ki jo ima stroj že zdaj.
Česa možnost proxy ne pokriva
Programi, ki ignorirajo konfiguracijo proxyja v brskalniku, ne bodo prizadeti zaradi ničesar od tega. Orodja ukazne vrstice, posodabljalniki in aplikacije z lastnim omrežnim skladom vzamejo usmerjevalno tabelo, ne datoteke PAC, zato ti primeri potrebujejo podprt mehanizem za posamezno aplikacijo ali drugačno zasnovo. Popišite odjemalce, ki so pomembni, preden obljubite, da pravilo brskalnika pokriva delovni tok.
Vrnitev neposredno tudi ni izhod v sili. Če politika usmerjanja stroja že pošilja vse v tunel, zahteva, označena kot neposredna, ostane znotraj njega, ker sta izbira proxyja in usmerjevalna tabela različni odločitvi, sprejeti na različnih plasteh.
Razreševanje imen je tretje ločeno vprašanje. Izbira, katere zahteve gredo na proxy, ne pove ničesar o tem, kateri razreševalnik jim odgovarja, in obravnavanje obeh kot ene nastavitve ustvari uhajanja, ki so nevidna, dokler nekdo ne preizkusi od zunaj. Odločite se, kje se odgovarja na vsako poizvedbo, in to odločitev zapišite poleg pravila proxyja. Razreševalnik, ki se spremeni, ker se je tunel dvignil, bo odgovor tiho premaknil.
Preizkusiti obe poti, ne le srečne
Preizkusite ime gostitelja, ki bi se moralo ujemati, ime gostitelja, ki se ne bi smelo, in vrh domene, ker je vrh primer, ki ga pravilo samo s pripono najpogosteje zgreši. Nato potrdite, katero pot je vsaka zahteva v resnici ubrala, namesto da bi to sklepali iz tega, ali se je stran naložila.
Na koncu preizkusite vejo napake. Nedosegljiv proxy bi moral odpovedati tako, kot ste se odločili vnaprej, namesto da bi se tiho vrnil na neposredno povezavo. Referenca omrežnih možnosti natančno dokumentira parametre poti; domenska polovica te zasnove živi povsem zunaj nje.