Hvorfor navneoppslag feiler over en rutet OpenVPN-tunnel

En vert svarer på ping med adresse og feiler på hvert oppslag med navn. Tunnelen er oppe og ruten finnes, så den naturlige konklusjonen er at VPN-en er feilkonfigurert. En mer nyttig konklusjon er at oppslaget aldri var rutbart: en rutet tunnel fører unicast-IP, mens forespørselen var en broadcast som lette etter et segment som ikke finnes på den andre siden. Når lagavviket først er synlig, sorterer løsningene seg selv etter kostnad.

Myte: tunnelen er ødelagt fordi navn feiler

Symptomet er overbevisende fordi alt over navnelaget fungerer. Adresser rutes, grensesnittet er oppe, og motparten svarer på ping. Det som feilet er en oppdagelsesmekanisme som aldri hadde en vei over en punkt-til-punkt-forbindelse, og det er en annen påstand enn en ødelagt tunnel. Å skille de to påstandene er det meste av diagnosen.

Behandles det som en tunnelfeil, fører det til profilendringer som ikke kan hjelpe. Å legge til valg, bytte kryptering eller reinstalere klienten lar broadcasten bli nøyaktig der den var.

Navngi mekanismen som feilet før du navngir løsningen. Et oppslag som bruker broadcast trenger et segment, mens et oppslag som bruker en resolver trenger en adresse å spørre.

Hva TUN fører og ikke fører

En TUN-enhet er et IP-grensesnitt, og det er det som gjør den rutbar. OpenVPN gir klienten en adresse og et sett ruter, og derfra sender klienten datagrammer til en motpart. Ingenting i den modellen skaper en delt forbindelse der hver vert hører hver ramme.

Oppdagelsestrafikk passer ikke i den modellen i det hele tatt. Eldre Windows-navneforespørsler, SSDP-kunngjøringer og mDNS-forespørsler sendes til alle på et segment i stedet for til én destinasjon. En rutet forbindelse har ingen «alle» å sende til. Hver av disse mekanismene forutsetter et delt medium.

Tunnelen kan derfor være sunn mens oppdagelsen feiler fullstendig. Det er den setningen man skal holde fast ved når noen melder at VPN-en er nede.

Broing virker ved å fjerne grensen

En TAP-enhet fører rammer, og en bro kobler den til et ekte LAN-segment. Klienten har da en adresse på det segmentet og hører broadcast-trafikken der. Derfor ser broing ut til å kurere navneproblemet. Det gjør også klienten avhengig av det segmentet for adressering.

Kuren er fjerning av rutegrensen, ikke noen ny navneevne inne i tunnelen. Alt segmentet broadcaster, krysser nå også forbindelsen.

For et lite laboratorium er det en rettferdig byttehandel. Over en spredt arbeidsstyrke er det sjelden.

Å skyve DNS og WINS ut er den smalere reparasjonen

Gi klienten et bestemt sted å spørre. dhcp-option DNS og dhcp-option DOMAIN peker interne navn mot en server som kjenner sonen, og en Windows-klient som fortsatt stoler på NetBIOS kan få en WINS-server på samme måte. Tunnelen forblir rutet, og segmentet blir der det hører hjemme.

To betingelser avgjør om det virker. Den navngitte serveren må svare for sonen, og forespørselen må være tillatt gjennom tunnelen.

Test resolveren fra klienten i stedet for fra serverens eget skall. En resolver som virker lokalt, sier ingenting om hva tunnelen fører.

Finn ut hvilket lag som feilet

Ping adressen først, løs deretter opp navnet og les hvilken server som svarte. Et negativt svar fra en server som ikke hoster sonen, ser annerledes ut enn en forespørsel som aldri forlot maskinen. Et navn som løses opp men avviser tilkoblinger, er et helt tredje problem.

Multicast står bak den samme veggen. En gruppe som 224.0.0.251 videresendes ikke over en rutet tunnel som standard, og en rute for gruppen er ikke nok uten en multicast-bevisst vei eller en reflektor på LAN-et.