Zergatik ezin duen komodin batek OpenVPN bide-direktiban funtzionatu

bideak helbide-prefixak instalatzen ditu, beraz ostalari-izenaren ereduak ez du ezer parekatzeko. Erabili prefixua sareetarako eta proxy bat edo PAC fitxategia domeinek erabaki behar dutenean.

Asmoa zentzuzkoa da: enpresa-domeinu baterako guztia tunelaren bidez bidaltzea eta gainerakoa bakean uztea. Editatzen ari den direktibak bideak instalatzen ditu, eta bide batek ez du parekatzeko ostalari-izenik. Komodin bat han idazteko saiakera bakoitzak parseatze-errore bat ematen du edo, okerrago, gaur egun kasualitatez funtzionatzen duen bide bat, izena helbide bakarrera ebaztu delako. Bi mekanismo desberdinei elkarren lana egitea eskatzen zaie.

Zer instalatzen duen bide batek eta zer ez duen inoiz irakurtzen

Bide-sarrera batek dio helmuga-prefix bat interfaze baten bidez irisgarria dela. Kernelak paketeak prefixu horiekin parekatzen ditu, beraz tartean dauden identifikatzaile bakarrak helbideak eta maskarak dira. Ostalari-izen bat ez da inoiz agertzen birbidalketa-erabakian, eta horregatik ezin da han eredurik parekatu.

OpenVPN gai da bide-parametro batzuetan ebatz daitekeen izen bat onartzeko, eta tolerantzia hori nahastearen iturri da. Izena konfigurazioa aplikatzen ari den bitartean ebazten da, bide arrunt bihurtzen diren helbide bat edo gehiago sortuz. Horren ondoren, izena erabat desagertzen da iruditik.

Beraz, izen batetik eraikitako bidea argazki bat da, ez arau bat. Tunela abiatu zen momentuan izen hori zer ebaztu zen hartzen du, eta hori da hain zuzen aldatzen den ostalari-familia baterako nahi ez duzun portaera. Bihar mugitzen den erregistro batek atzokoari seinalatzen uzten du bidea.

Helmuga benetan prefixu bat denean

Helburua sare pribatu ezagun bat bada, idatzi prefixua. Dokumentazio-espazioko adibide baterako, ostalari bakar bat eta azpisare bat horrela ikusten dira:

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

Bi sarrerek helbideak eta maskarak izendatzen dituzte, eta biek DNS aldaketei aurre egiten diete, haietan ezer ez delako izen baten mende. Abantaila osoa hori da: bidea topologiari buruzko adierazpen bat da, behin gertatu zen bilaketa bati buruzkoa beharrean.

Ez atera prefixu handirik DNS erantzun bakar batetik. Helbide bakarrera ebazten den ostalari-izen batek ez dizu ezer esaten haren atzeko sarearen tamainaz, eta asmatutako prefixua da tunela inork bidez bidali nahi ez zuen trafikoa harrapatzen hasteko modua. Galdetu sarearen jabearentzat benetako prefixua, bilaketa batetik ondorioztatu beharrean.

Lana unitatea ostalari-izen bat denean

Domeinuaren araberako hautaketak domeinua irakurtzen duen zerbait behar du, hau da, aplikazio-geruzako osagai bat. Erantzun ohikoa tunelaren beste aldean bizi den HTTP proxy bat da, eta bezeroak aukeratzen du zein eskaera bidaltzen dion.

Proxy konfigurazio fitxategi batek hautaketa hori adieraz dezake. Beheko arau ilustratiboek domeinu bat eta haren azpidomeinuak proxy batera bidaltzen dituzte, eta gainerako guztia zuzenean:

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

Izen zehatzaren konparazioak domeinua bera hartzen du, eta atzizkiaren konparazioak haren seme-alabak hartzen ditu, antzeko karaktereetan amaitzen den izen bat parekatu gabe. Biak beharrezkoak dira, eta bat baztertzeak zuzena dirudien eta erpina edo iruzurti bat saltatzen duen araua sortzen du.

Arau hauek proxy bat aukeratzen dute; ez dute horrelakorik sortzen, eta ez dute sistema eragilearen biderik aldatzen. Proxyaren helbideak oraindik bere bidea behar du tuneletik, eta zuzentzat markatutako eskaerek makina dagoeneko duen bideratze-politikari jarraitzen diote.

Proxy aukerak estaltzen ez duena

Nabigatzailearen proxy konfigurazioari jaramonik egiten ez dioten programei horietako ezerk ez die eragingo. Komando-lerroko tresnek, eguneratzeko programek eta sare-pila propioa duten aplikazioek bide-taulak hartzen dituzte, ez PAC fitxategiak, beraz kasu horiek onartutako aplikazio bakoitzeko mekanismoa edo beste diseinu bat behar dute. Zerrendatu garrantzitsuak diren bezeroak, nabigatzailearen arauak lan-fluxua estaltzen duela agindu aurretik.

Zuzenean itzultzea ere ez da ihesbidea. Makinaren bideratze-politikak dagoeneko guztia tunelera bidaltzen badu, zuzentzat markatutako eskaera haren barruan geratzen da, proxy hautaketa eta bide-taula geruza desberdinetan hartutako erabaki desberdinak direlako.

Izenen ebazpena hirugarren gai bereizia da. Zein eskaera proxy batera doazen aukeratzeak ez du ezer esaten zein ebaztek erantzuten dien, eta biak ezarpen bakar gisa tratatzeak kanpotik norbait probatu arte ikusezinak diren ihesak sortzen ditu. Erabaki non erantzuten zaion kontsulta bakoitzari, eta idatzi erabaki hori proxy arauaren ondoan. Tunela igo delako aldatzen den ebaztek isilka mugituko du erantzuna.

Bi bideak probatzea, ez zoriontsua bakarrik

Probatu parekatu beharko lukeen ostalari-izen bat, parekatu beharko ez lukeena, eta domeinuaren erpina, erpina delako atzizki-soileko arau batek gehien saltatzen duen kasua. Gero egiaztatu eskaera bakoitzak benetan zein bide hartu zuen, orria kargatu zen ala ezetik ondorioztatu beharrean.

Azkenik, probatu hutsegite-adarra. Irisgarria ez den proxy batek aldez aurretik erabaki duzun moduan huts egin beharko luke, isilka konexio zuzenera itzuli beharrean. Bide-parametroak zehaztasunez dokumentatzen dira sare-aukerei buruzko erreferentzian; diseinu honen domeinu-erdia erabat dago haren kanpo.

Erlazionatutako artikuluak