Kvifor namneoppslag feilar over ein ruta OpenVPN-tunnel

Ein vert svarar på ping med adresse og feilar på kvart oppslag med namn. Tunnelen er oppe og ruta finst, så den naturlege konklusjonen er at VPN-en er feilkonfigurert. Ein meir nyttig konklusjon er at oppslaget aldri var rutbart: ein ruta tunnel fører unicast-IP, medan førespurnaden var ein broadcast som leitte etter eit segment som ikkje finst på hi sida. Når lagavviket er synleg, sorterer løysingane seg sjølve etter kostnad.

Myte: tunnelen er øydelagd fordi namn feilar

Symptomet er overtydande fordi alt over namnelaget fungerer. Adresser vert ruta, grensesnittet er oppe, og motparten svarar på ping. Det som feila er ein oppdagingsmekanisme som aldri hadde ein veg over ei punkt-til-punkt-samband, og det er ein annan påstand enn ein øydelagd tunnel. Å skilje dei to påstandane er det meste av diagnosen.

Vert det handsama som ein tunnelfeil, fører det til profilendringar som ikkje kan hjelpe. Å leggje til val, byte kryptering eller reinstalere klienten lèt broadcasten bli nøyaktig der han var.

Namngi mekanismen som feila før du namngir løysinga. Eit oppslag som brukar broadcast treng eit segment, medan eit oppslag som brukar ein resolver treng ei adresse å spørje.

Kva TUN fører og ikkje fører

Ei TUN-eining er eit IP-grensesnitt, og det er det som gjer henne rutbar. OpenVPN gjev klienten ei adresse og eit sett ruter, og derifrå sender klienten datagram til ein motpart. Ingenting i den modellen skaper ei delt samband der kvar vert høyrer kvar ramme.

Oppdagingstrafikk passar ikkje i den modellen i det heile. Eldre Windows-namneførespurnader, SSDP-kunngjeringar og mDNS-førespurnader vert sende til alle på eit segment i staden for til éin destinasjon. Ei ruta samband har ingen «alle» å sende til. Kvar av desse mekanismane føreset eit delt medium.

Tunnelen kan difor vere sunn medan oppdaginga feilar fullstendig. Det er den setninga ein skal halde fast i når nokon melder at VPN-en er nede.

Bruing verkar ved å fjerne grensa

Ei TAP-eining fører rammer, og ei bru knyter henne til eit ekte LAN-segment. Klienten har då ei adresse på det segmentet og høyrer broadcast-trafikken der. Difor ser bruing ut til å kure namneproblemet. Det gjer også klienten avhengig av det segmentet for adressering.

Kuren er fjerning av rutegrensa, ikkje noka ny namneevne inne i tunnelen. Alt segmentet broadcaster, kryssar no også sambandet.

For eit lite laboratorium er det ein rettferdig byttehandel. Over ein spreidd arbeidsstyrke er det sjeldan.

Å skyve DNS og WINS ut er den smalare reparasjonen

Gje klienten ein bestemt stad å spørje. dhcp-option DNS og dhcp-option DOMAIN peikar interne namn mot ein tenar som kjenner sona, og ein Windows-klient som enno stolar på NetBIOS kan få ein WINS-tenar på same måte. Tunnelen blir verande ruta, og segmentet blir der det høyrer heime.

To vilkår avgjer om det verkar. Den namngjevne tenaren må svare for sona, og førespurnaden må vere tillaten gjennom tunnelen.

Test resolveren frå klienten i staden for frå skalet til tenaren sjølv. Ein resolver som verkar lokalt, seier ingenting om kva tunnelen fører.

Finn ut kva lag som feila

Ping adressa fyrst, løys deretter opp namnet og les kva tenar som svara. Eit negativt svar frå ein tenar som ikkje hostar sona, ser annleis ut enn ein førespurnad som aldri forlét maskina. Eit namn som løyser seg opp men avviser tilkoplingar, er eit heilt tredje problem.

Multicast står bak den same veggen. Ei gruppe som 224.0.0.251 vert ikkje vidaresend over ein ruta tunnel som standard, og ei rute for gruppa er ikkje nok utan ein multicast-medviten veg eller ein reflektor på LAN-et.