Waarom naamopsoeke oor 'n gerouteerde OpenVPN-tonnel misluk

'n Gasheer antwoord ping per adres en misluk elke opsoek per naam. Die tonnel is op en die roete bestaan, so die natuurlike gevolgtrekking is dat die VPN verkeerd gekonfigureer is. 'n Nuttiger gevolgtrekking is dat die opsoek nooit roetebaar was nie: 'n gerouteerde tonnel dra unicast-IP, terwyl die betrokke navraag 'n uitsending was wat na 'n segment soek wat nie aan die ander kant bestaan nie. Sodra die laagverskil sigbaar is, sorteer die oplossings hulself volgens koste.

Mite: die tonnel is stukkend omdat name misluk

Die simptoom is oortuigend omdat alles bokant die naamlaag werk. Adresse word gerouteer, die koppelvlak is op, en die eweknie antwoord op 'n ping. Wat gefaal het, is 'n ontdekkingsmeganisme wat nooit 'n pad oor 'n punt-tot-punt-skakel gehad het nie, en dit is 'n ander stelling as 'n stukkende tonnel. Om daardie twee stellings te skei, is die grootste deel van die diagnose.

Om dit as 'n tonnelfout te behandel, lei tot profielwysigings wat nie kan help nie. Om opsies by te voeg, die enkripsie te verander of die kliënt te herinstalleer, laat die uitsending presies waar dit was.

Noem die meganisme wat gefaal het voordat jy die oplossing noem. 'n Opsoek wat uitsending gebruik, het 'n segment nodig, terwyl 'n opsoek wat 'n oplosser gebruik, 'n adres nodig het om te vra.

Wat TUN wel en nie dra nie

'n TUN-toestel is 'n IP-koppelvlak, en dit is wat dit roetebaar maak. OpenVPN gee die kliënt 'n adres en 'n stel roetes, en van daar af stuur die kliënt datagramme na 'n eweknie. Niks in daardie model skep 'n gedeelde skakel waar elke gasheer elke raam hoor nie.

Ontdekkingsverkeer pas glad nie by daardie model nie. Ouer Windows-naamnavrae, SSDP-aankondigings en mDNS-versoeke word aan almal op 'n segment gestuur eerder as na een bestemming. 'n Gerouteerde skakel het geen almal om na te stuur nie. Elkeen van daardie meganismes veronderstel 'n gedeelde medium.

Die tonnel kan dus gesond wees terwyl ontdekking heeltemal misluk. Daardie sin is die een om vas te hou wanneer iemand rapporteer dat die VPN af is.

Brugging werk deur die grens te verwyder

'n TAP-toestel dra rame, en 'n brug heg dit aan 'n werklike LAN-segment. Die kliënt hou dan 'n adres op daardie segment en hoor sy uitsaai-verkeer. Dit is waarom brugging die naamprobleem blyk te genees. Dit maak ook die kliënt afhanklik van daardie segment vir adressering.

Die genesing is die verwydering van die roetegrens, nie enige nuwe naamvermoë binne die tonnel nie. Alles wat die segment uitsaai, steek nou ook die skakel oor.

Vir 'n klein laboratorium is dit 'n billike ruil. Oor 'n verspreide werkmag is dit selde.

Om DNS en WINS te stoot is die smaller herstel

Gee die kliënt 'n spesifieke plek om te vra. dhcp-option DNS en dhcp-option DOMAIN wys interne name na 'n bediener wat die sone ken, en 'n Windows-kliënt wat nog op NetBIOS staatmaak, kan op dieselfde manier 'n WINS-bediener ontvang. Die tonnel bly gerouteer en die segment bly waar dit hoort.

Twee voorwaardes bepaal of dit werk. Die genoemde bediener moet vir die sone antwoord, en die navraag moet deur die tonnel toegelaat word.

Toets die oplosser vanaf die kliënt eerder as vanaf die bediener se eie dop. 'n Oplosser wat plaaslik werk, sê niks oor wat die tonnel dra nie.

Vind uit watter laag gefaal het

Ping eers die adres, los dan die naam op en lees watter bediener geantwoord het. 'n Negatiewe antwoord van 'n bediener wat nie die sone huisves nie, lyk anders as 'n navraag wat nooit die masjien verlaat het nie. 'n Naam wat oplos maar verbindings weier, is 'n heeltemal derde probleem.

Multicast sit agter dieselfde muur. 'n Groep soos 224.0.0.251 word nie by verstek oor 'n gerouteerde tonnel gestuur nie, en 'n roete vir die groep is nie genoeg sonder 'n multicast-bewuste pad of 'n reflektor op die LAN nie.