BIND VPN baten gainean: birbidalketa baldintzapekoa edo stub zona?

Zona pribatu bat VPN baten bidez ebazteko hiru modu eta bakoitza noiz den egokia: forward, stub edo secondary, eta erabakia hartzen duen jatorrizko helbidearen egiaztapena.

Zure bulegoko resolverrak dena erantzuten du enpresa-namespace bat izan ezik, eta hura ezagutzen duen enpresa DNS zerbitzaria VPN baten atzean dago. BINDek zona bakar hori upstreamari hiru eratan eman diezaioke, eta modu desberdinean huts egiten dute. Birbidalketa baldintzapekoa da konpromiso txikiena, stub zonak delegazio-datuak gordetzen ditu, eta secondaryk kopia osoa gordetzen du. Aukeratu upstreamak zer onartuko duen eta zure resolverrak zer gorde nahi duzun kontuan hartuta, ez lehenago aurkitu duzun fragmentuaren arabera.

Hiru antolamendu namespace baterako

TypeWhat your resolver keepsUpstream mustFails when
forwarda forwarder listanswer queries from your source addressupstream is down and forward only is set
stubthe zone's NS records and addressesanswer NS queries for the zonedelegation data goes stale after an NS change
secondarya full copy of the zonepermit AXFR or IXFR from your sourcetransfer is blocked by ACL or firewall

Birbidalketa baldintzapekoa: konpromiso txikiena

Demagun 192.168.10.53ko bulegoko resolver bat eta 10.40.0.53ko enpresa zerbitzari bat, onartutako tunel baten bidez irisgarria. Deklarazioak hiru lerro ditu, eta interesgarriena forward only da, porrotaren portaera aldatzen baitu, ez bidea.

zone "corp.example" {
    type forward;
    forward only;
    forwarders { 10.40.0.53; };
};

forward only aktibo dagoenean, upstream irisgaitzak SERVFAIL bat sortzen du zona honentzat, ebazpen iteratibora erortzen den ordez. Hori da normalean nahi duzuna namespace pribatu baterako, erorketak izen pribatuak resolver publikora bidaliko lituzkeelako eta internetetik erantzun erabilgaitza itzuliko lukeelako. BIND erreferentzia bi politikak dokumentatzen ditu, eta aldea fragmentuak iradokitzen duena baino garrantzitsuagoa da. Batu zona lehendik dagoen konfigurazioari, izen bererako lehendik dagoen zona ordeztu beharrean.

Stub edo secondary: delegazioa garrantzitsua denean

Stub zona batek enpresa zerbitzariari zonaren NS erregistroak eskatzen dizkio eta gero autoritatezko zerbitzariei zuzenean galdetzen die. Aukeratu upstream eskualdea handia edo azpizatikatua denean eta zure resolverrak delegazioari jarraitzea nahi duzunean, dena helbide bakarrera lotu beharrean. Kostua NS datuek eguneratuak egon behar dutela eta zerrendatutako izen-zerbitzari bakoitza zure resolverraren jatorrizko helbidetik irisgarria izan behar dela da.

zone "corp.example" {
    type stub;
    masters { 10.40.0.53; };
};

zone "corp.example" {
    type secondary;
    primaries { 10.40.0.53; };
    file "corp.example.db";
};

Secondary bat tokiko datuekin erantzuten du eta upstream etena gainditzen du, eta hori da transferentzia-mendekotasuna onartzeko arrazoia. Esan nahi du, halaber, zure resolverrak orain ez duen zona baten kopia gordetzen duela, beraz fitxategiaren bidea, primarioaren transferentzia ACL eta freskatze-tenporizadoreak zure eragiketa-azaleraren parte bihurtzen dira.

Haien artean erabakitzen duen egiaztapena

BINDek bere irteerako kontsulta sortzen du, beraz galdera ez da ordenagailu eramangarri bat 10.40.0.53ra irits daitekeen, baizik eta resolverraren ostalariak bai, enpresa zerbitzariak ikusiko duen jatorrizko helbidetik. Galdetu kernelari, gero zerbitzariari, ordena horretan.

ip route get 10.40.0.53
named-checkconf
rndc reload corp.example
dig @10.40.0.53 corp.example NS +norecurse
dig @192.168.10.53 portal.corp.example

Baimendu UDP eta TCP bidean: moztutako erantzun batek TCP behartzen du, eta soilik UDP onartzen duen politikak pakete-galeraren antzeko hutsegite intermitenteak sortzen ditu. Enpresa aldeak zure resolverraren jatorrirako onarpen-araua eta hara itzultzeko bidea behar ditu; jatorri hori resolverraren bideratutako helbidea edo esplizituki itzulitako bat izan daiteke, eta gutxitan da bezero-pool baten helbidea. NS kontsultak huts egiten badu, stub zona batek ezin du funtzionatu forward zonak nola jokatzen duen ere.

Egiaztatu erantzuna, ez tunela

Galdetu bulegoko resolverraren bidez inoiz eskatu ez duzun izen bat, eta begiratu erantzunaren authority atala enpresa zonatik etorri den jakiteko. Cachean gordetako erantzunak ez du ezer frogatzen uneko bideari buruz, eta upstreamari zuzenean egindako kontsulta arrakastatsuak ez du frogatzen zure resolverrak zona hori aukeratu duenik. Errepikatu kontsulta bera TCP bidez, bideak mozketa gainditzen duela baieztatzeko.

Eduki bezeroak bulegoko resolverrera begira, eta eduki DNSSEC balidazioa aktibatuta. Resolver enkriptatu independente batekin konfiguratutako nabigatzaile batek antolamendu hau guztiz saihesten du, eta balidazioa desaktibatzeak erantzun ezustekoa zuzena dirudien itxura ona egiteko hutsegite ikusgai bat ikusezin batekin trukatzen du.

Idatzi hiru motetatik zein aukeratu duzun eta zergatik. Zona huts egiten ikusiko duen hurrengo pertsonak esaldi hori beharko du konfigurazio-fitxategia baino gehiago.

Erlazionatutako artikuluak