Wêrom in wildcard yn in OpenVPN-route-ynstruksje net wurkje kin

de route ynstallearret adresprefiks, dat in hostnamemuster hat neat om mei te ferliken. Brûk in prefiks foar netwurken en in proxy of in PAC-triem as domeinen beslisse moatte.

It doel is ridlik: alles foar ien bedriuwsdomein troch de tunnel stjoere en de rest gewurde litte. De ynstruksje dy't bewurke wurdt ynstallearret routes, en in route hat gjin begryp fan in hostnamme om mei te ferliken. Eltse poging om der in wildcard yn te skriuwen leveret óf in parseflater óf, slimmer, in route dy't hjoed tafallich wurket om't de namme nei ien adres oplost is. Twa ferskillende meganismen wurde frege om inoars wurk te dwaan.

Wat in route ynstallearret, en wat er nea lêst

In route-ynfier seit dat in bestimmingprefiks fia in ynterface berikber is. De kearn ferliket pakketten mei dy prefiksen, dat de iennige belutsen identifikatoren binne adressen en masken. In hostnamme komt nea yn it trochstjoerbeslút foar, en dêrom kin in patroan dêr net ferlike wurde.

OpenVPN kin yn guon route-parameters in oplosbere namme akseptearje, en dy tolerânsje is in boarne fan betizing. De namme wurdt oplost wylst de konfiguraasje tapast wurdt, wat ien of mear adressen opleveret dy't gewoane routes wurde. Dêrnei is de namme hielendal út byld.

Sa is in route boud út in namme in momintopname, gjin regel. Hy dekt wat dy namme oplost is op it momint dat de tunnel begûn, en dat is krekt it gedrach dat jo net wolle foar in famylje hosts dy't feroaret. In record dy't moarn ferhuze, lit de route nei juster wize.

As de bestimming echt in prefiks is

As it doel in bekend priveenetwurk is, skriuw dan it prefiks. Foar in foarbyld út 'e dokumintaasjeromte sjogge in inkelde host en in subnet der sa út:

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

Beide ynfieringen neame adressen en masken, en beide oerlibje DNS-feroarings om't neat deroan fan in namme ôfhinklik is. Dat is it hiele foardiel: de route is in útspraak oer topology, net oer in syktocht dy't ien kear barde.

Lûk gjin grut prefiks út ien DNS-antwurd. Ien hostnamme dy't nei ien adres oplost, seit jo neat oer de grutte fan it netwurk dêrefter, en in rieden prefiks is hoe't in tunnel úteinlik ferkear fangt dat nimmen fan doel wie der troch te stjoeren. Freegje de netwurkeigner om it wiere prefiks ynstee fan it út in syktocht ôf te lûken.

As de wurkeenheid in hostnamme is

Seleksje op domein freget wat dat it domein lêst, dat wol sizze in komponint op applikaasjenivo. It gewoane antwurd is in HTTP-proxy dy't oan 'e oare kant fan 'e tunnel wennet, wêrby't de klant kiest hokker oanfragen dêrhinne stjoerd wurde.

In proxy-konfiguraasjetriem kin dy kar útdrukke. De yllustrative regels hjirûnder stjoere ien domein en syn subdomeinen nei in proxy en al it oare direkt:

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

De ferliking fan 'e eksakte namme dekt it domein sels, en de efterheakselferliking dekt syn bern sûnder in namme te ferliken dy't gewoan op ferlykbere tekens einiget. Beide binne nedich, en ien weilitte leveret in regel op dy't goed liket en de top as in bedrager oerslacht.

Dizze regels kieze in proxy; se meitsje der gjin en se feroarje gjin inkel bestjoeringssysteem-route. It proxy-adres hat noch altyd syn eigen paad troch de tunnel nedich, en oanfragen dy't as direkt markearre binne folgje noch altyd it routeringsbelied dat de masine al hat.

Wat de proxy-opsje net dekt

Programma's dy't de proxy-konfiguraasje fan 'e browser negearje, wurde troch neat hjirfan beynfloede. Kommandorigel-ark, fernijers en applikaasjes mei har eigen netwurkstapel nimme de routetabel, net it PAC-triem, dat dy gefallen hawwe in stipe meganisme per applikaasje of in oar ûntwerp nedich. Ynventarisearje de klanten dy't fan belang binne foardat jo belove dat de browserregel de wurkstream dekt.

Direkt weromgeane is ek gjin ûntwyk. As it routeringsbelied fan 'e masine al alles yn 'e tunnel stjoert, bliuwt in oanfraach dy't as direkt markearre is derbinnen, om't de proxykar en de routetabel ferskillende besluten binne dy't op ferskillende lagen nommen wurde.

Nammesolving is in tredde aparte fraach. It kiezen hokker oanfragen nei in proxy geane, seit neat oer hokker resolver se beantwurdet, en it behanneljen fan 'e beide as ien ynstelling leveret lekken op dy't ûnsichtber binne oant immen fan bûten testet. Beslis wêr't elke fraach beantwurde wurdt en skriuw dat beslút njonken de proxyregel. In resolver dy't feroaret om't de tunnel omheech kaam, sil it antwurd stil ferpleatse.

Beide paden testen, net allinnich de lokkige

Test in hostnamme dy't ferwachtet te passen, in hostnamme dy't net passe moat, en de top fan it domein, om't de top it gefal is dat it meast troch in regel allinnich mei efterheaksel mist wurdt. Befestigje dan hokker paad elke oanfraach eins naam, ynstee fan it ôf te lûken út oft de side laden is.

Test op 't lêst de flatertûke. In proxy dy't net berikber is, moat falle op in manier dy't jo foarôf besletten hawwe, ynstee fan stil werom te fallen op in direkte ferbining. De referinsje foar netwurkopsjes dokumintearret de route-parameters sekuer; de domeinhelte fan dit ûntwerp libbet hielendal bûten dy.

Relatearre artikelen