Zergatik huts egiten duten izen-bilaketek bideratutako OpenVPN tunel batean
Bideratutako TUN tunelak unicast IP soilik garraiatzen du, beraz broadcast bidezko izen-kontsultak ez zuen inoiz horrako biderik izan. Zubiak muga kentzen du; DNS bultzatzea da konponbide merkeena.
Ostalariak ping-ari helbidearen arabera erantzuten dio eta izen bidezko bilaketa guztietan huts egiten du. Tunela altxatuta dago eta bidea badago, beraz ondorio naturala VPN-a gaizki konfiguratuta dagoela da. Ondorio baliagarriagoa da bilaketa ez zela inoiz bideragarria izan: bideratutako tunelak unicast IP garraiatzen du, eta kontsulta broadcast bat zen, beste aldean existitzen ez den segmentu baten bila. Geruzen arteko desdoitzea ikusgai dagoenean, konponbideek beren kabuz sailkatzen dira kostuaren arabera.
Mitoa: tunela hondatuta dago izenek huts egiten dutelako
Sintoma sinesgarria da izen-geruzaren gaineko guztiak funtzionatzen duelako. Helbideak bideratzen dira, interfazea altxatuta dago eta parekoak ping-ari erantzuten dio. Huts egin zuen puntu-puntuko esteka batetik inoiz biderik izan ez zuen aurkikuntza-mekanismo batek, eta hori beste baieztapen bat da, tunel hondatu batena ez bezalakoa. Bi baieztapen horiek bereiztea da diagnostikoaren zatirik handiena.
Tunelaren akats gisa hartuta, ezin duen lagundu profila aldatzea dakar. Aukerak gehitzeak, zifratzea aldatzeak edo bezeroa berriz instalatzeak broadcast-a leku berean uzten du.
Izenda ezazu huts egin zuen mekanismoa konponbidea izendatu aurretik. Broadcast-a erabiltzen duen bilaketak segmentua behar du, eta resolver bat erabiltzen duen bilaketak galdetzeko helbidea behar du.
Zer garraiatzen du TUN-ek eta zer ez
TUN gailua IP interfaze bat da, eta horrek egiten du bideragarri. OpenVPN bezeroari helbide bat eta bide multzo bat ematen dizkio, eta ordutik bezeroak datagramak bidaltzen dizkio pareko bati. Eredu horretan ezerk ez du esteka partekatu bat sortzen, non ostalari bakoitzak marko bakoitza entzuten duen.
Aurkikuntza-trafikoak ez du batere egokitzen eredu horretan. Windows-en izen-kontsulta zaharrak, SSDP iragarpenak eta mDNS eskaerak segmentu bateko guztiei bidaltzen zaizkie, helmuga bakarrari beharrean. Bideratutako esteka batek ez du «denak» bat bidaltzeko. Mekanismo horietako bakoitzak medio partekatu bat suposatzen du.
Beraz tunela osasuntsu egon daiteke aurkikuntzak erabat huts egiten duen bitartean. Esaldi hori da atxikitzekoa norbaitek VPN-a erorita dagoela jakinarazten duenean.
Zubiak muga kenduz funtzionatzen du
TAP gailuak markoak garraiatzen ditu, eta zubi batek benetako LAN segmentu batera lotzen du. Orduan bezeroak segmentu horretan helbide bat du eta haren broadcast trafikoa entzuten du. Horregatik dirudi zubiak izen-arazoa sendatzen duenik. Bezeroa helbideratzeko segmentu horren menpe ere uzten du.
Sendabidea bideratze-muga kentzea da, ez tunelaren barruko izen-gaitasun berri bat. Segmentuak broadcast bidez bidaltzen duen guztia estekatik ere igarotzen da orain.
Laborategi txiki batentzat truke justua da. Banatutako lan-talde batentzat gutxitan.
DNS eta WINS bultzatzea da konponbide estuena
Eman bezeroari galdetzeko leku zehatz bat. dhcp-option DNS eta dhcp-option DOMAIN barne-izenak zona ezagutzen duen zerbitzari batera bideratzen dituzte, eta NetBIOS-en oraindik oinarritzen den Windows bezero batek WINS zerbitzari bat jaso dezake modu berean. Tunela bideratuta geratzen da eta segmentua bere lekuan geratzen da.
Bi baldintzak erabakitzen dute horrek funtzionatuko duen. Izendatutako zerbitzariak zonaren erantzuna eman behar du, eta kontsultari tunelaren bidez baimendu behar zaio.
Proba ezazu resolver-a bezeroaren aldetik, zerbitzariaren shell-etik baino. Lokalean funtzionatzen duen resolver batek ez du ezer esaten tunelak zer garraiatzen duen.
Jakizu zein geruzak huts egin zuen
Ping egin helbideari lehenik, gero izena ebatzi eta irakurri zein zerbitzarik erantzun zuen. Zona ostatu ez duen zerbitzari baten erantzun ezezkoak beste itxura du makina inoiz utzi ez zuen kontsulta batek. Ebazten den baina konexioak ukatzen dituen izena erabat hirugarren arazoa da.
Multicast horma beraren atzean dago. 224.0.0.251 moduko talde bat ez da lehenespenez bideratutako tunel batetik birbidaltzen, eta taldearen bidea ez da nahikoa multicast-a ulertzen duen bide edo LAN-eko islatzaile bat gabe.