Hvorfor navneopslag fejler over en routet OpenVPN-tunnel

En vært svarer på ping via adresse og fejler ved hvert opslag på navn. Tunnelen er oppe, og ruten findes, så den naturlige konklusion er, at VPN'en er fejlkonfigureret. En mere nyttig konklusion er, at opslaget aldrig var rutbart: en routet tunnel bærer unicast-IP, mens forespørgslen var en broadcast, der ledte efter et segment, som ikke findes på den anden side. Når lag-uoverensstemmelsen er synlig, sorterer løsningerne sig selv efter pris.

Myte: tunnelen er i stykker, fordi navne fejler

Symptomet er overbevisende, fordi alt over navnelaget virker. Adresser routes, interfacet er oppe, og peer'en svarer på ping. Det, der fejlede, er en opdagelsesmekanisme, som aldrig har haft en vej over en punkt-til-punkt-forbindelse, og det er en anden udtalelse end en ødelagt tunnel. At skelne mellem de to udtalelser er det meste af diagnosen.

Behandles det som en tunnelfejl, fører det til profilændringer, som ikke kan hjælpe. At tilføje valgmuligheder, skifte kryptering eller geninstallere klienten efterlader broadcasten præcis, hvor den var.

Navngiv den mekanisme, der fejlede, før du navngiver løsningen. Et opslag, der bruger broadcast, har brug for et segment, mens et opslag, der bruger en resolver, har brug for en adresse at spørge.

Hvad TUN bærer, og hvad den ikke bærer

En TUN-enhed er et IP-interface, og det er det, der gør den rutbar. OpenVPN giver klienten en adresse og et sæt ruter, og derefter sender klienten datagrammer til en peer. Intet i den model skaber en delt forbindelse, hvor hver vært hører hver ramme.

Opdagelsestrafik passer slet ikke i den model. Ældre Windows-navneforespørgsler, SSDP-meddelelser og mDNS-anmodninger sendes til alle på et segment i stedet for til én destination. En routet forbindelse har ingen «alle» at sende til. Hver af disse mekanismer forudsætter et delt medie.

Tunnelen kan derfor være sund, mens opdagelse fejler fuldstændigt. Den sætning er den, man skal holde fast i, når nogen rapporterer, at VPN'en er nede.

Brodannelse virker ved at fjerne grænsen

En TAP-enhed bærer rammer, og en bro forbinder den til et rigtigt LAN-segment. Klienten har derefter en adresse på det segment og hører dets broadcasttrafik. Derfor ser brodannelse ud til at kurere navneproblemet. Det gør også klienten afhængig af det segment for adressering.

Kuren er fjernelse af routinggrænsen, ikke nogen ny navneevne inde i tunnelen. Alt, hvad segmentet broadcaster, krydser nu også forbindelsen.

For et lille laboratorium er det en fair byttehandel. På tværs af en spredt arbejdsstyrke er det sjældent.

At skubbe DNS og WINS ud er den smallere reparation

Giv klienten et bestemt sted at spørge. dhcp-option DNS og dhcp-option DOMAIN peger interne navne mod en server, der kender zonen, og en Windows-klient, der stadig stoler på NetBIOS, kan få en WINS-server på samme måde. Tunnelen forbliver routet, og segmentet bliver, hvor det hører til.

To betingelser afgør, om det virker. Den nævnte server skal svare for zonen, og forespørgslen skal være tilladt gennem tunnelen.

Test resolvere fra klienten i stedet for fra serverens egen skal. En resolver, der virker lokalt, siger intet om, hvad tunnelen bærer.

Find ud af, hvilket lag der fejlede

Ping adressen først, og slå derefter navnet op, og læs, hvilken server der svarede. Et negativt svar fra en server, der ikke hoster zonen, ser anderledes ud end en forespørgsel, der aldrig forlod maskinen. Et navn, der slås op, men afviser forbindelser, er et helt tredje problem.

Multicast står bag den samme mur. En gruppe som 224.0.0.251 videresendes ikke over en routet tunnel som standard, og en rute for gruppen er ikke nok uden en multicast-bevidst vej eller en reflektor på LAN'et.