Wêrom nammeopsiken mislearje oer in rûte OpenVPN-tunnel

In host antwurdet ping op adres en mislearret elk opsyk by namme. De tunnel stiet en de rûte bestiet, dus de natuerlike konklúzje is dat de VPN ferkeard konfigurearre is. In nuttiger konklúzje is dat it opsyk nea rûteber wie: in rûte tunnel draacht unicast-IP, wylst de query in broadcast wie dy't socht nei in segmint dat oan de oare kant net bestiet. Sadree't de laachôfwiking sichtber is, sortearje de oplossingen harsels op kosten.

Myt: de tunnel is stikken om't nammen mislearje

It symptoom is oertsjûgjend om't alles boppe de namme-laach wurket. Adressen wurde rûte, de ynterface stiet, en de peer antwurdet op in ping. Wat mislearre is in ûntdekkingsmeganisme dat nea in paad oer in puntsje-nei-puntsje-ferbining hie, en dat is in oare útspraak as in stikken tunnel. It skieden fan dy twa útspraken is it grutste part fan 'e diagnoaze.

It behanneljen as in tunnelbrek liedt ta profylwizigings dy't net helpe kinne. Opsjes tafoegje, de fersifering feroarje of de klient opnij ynstallearje lit de broadcast krekt dêr wêr't er wie.

Nammefoarm it meganisme dat mislearre foardat jo de oplossing nammefoarmje. In opsyk dy't broadcast brûkt hat in segmint nedich, wylst in opsyk dy't in resolver brûkt in adres nedich hat om te freegjen.

Wat TUN draacht en wat net

In TUN-apparaat is in IP-ynterface, en dat is wat it rûteber makket. OpenVPN jout de klient in adres en in set rûtes, en fanôf dat stuit stjoert de klient datagrammen nei in peer. Neat yn dat model makket in dielde ferbining wêr't elke host elk frame heart.

Ûntdekkingferkear past hielendal net yn dat model. Aldere Windows-nammequeries, SSDP-oankundigings en mDNS-fersiken wurde nei elkenien op in segmint stjoerd yn stee fan nei ien bestimming. In rûte ferbining hat gjin «elkenien» om nei te stjoeren. Elk fan dy meganismen ferûnderstelt in dield medium.

De tunnel kin dus sûn wêze wylst ûntdekking folslein mislearret. Dy sin is dejinge om oan fêst te hâlden as immen rapportearret dat de VPN del is.

Bridzje wurket troch de grins fuort te heljen

In TAP-apparaat draacht frames, en in brêge ferbynt it oan in echte LAN-segmint. De klient hat dan in adres op dat segmint en heart it broadcast-ferkear. Dêrom liket bridzje it nammerprobleem te genêzen. It makket de klient ek ôfhinklik fan dat segmint foar adressearring.

De genêzing is it fuorthheljen fan 'e rûtegrins, net in nije nammekapasiteit yn 'e tunnel. Alles wat it segmint broadcast, giet no ek oer de ferbining.

Foar in lyts laboratoarium is dat in earlike ruil. Oer in ferspraat personiel selden.

DNS en WINS trochdrukke is de smellere reparaasje

Jou de klient in beskate plak om te freegjen. dhcp-option DNS en dhcp-option DOMAIN wize ynterne nammen nei in tsjinner dy't de sône ken, en in Windows-klient dy't noch op NetBIOS fertrout kin op deselde wize in WINS-tsjinner krije. De tunnel bliuwt rûte en it segmint bliuwt wêr't it heart.

Twa betingsten bepale oft dat wurket. De neamde tsjinner moat foar de sône antwurdzje, en de query moat troch de tunnel tastien wurde.

Test de resolver fan de klient ôf, net fan 'e eigen shell fan 'e tsjinner. In resolver dy't lokaal wurket seit neat oer wat de tunnel draacht.

Fyn út hokker laach mislearre

Pingje earst it adres, oplos dan de namme en lês hokker tsjinner antwurde. In negatyf antwurd fan in tsjinner dy't de sône net hostet sjocht der oars út as in query dy't de masine nea ferlitten hat. In namme dy't oplost mar ferbinings wegeret is in hiel trêde probleem.

Multicast stiet efter deselde muorre. In groep as 224.0.0.251 wurdt standert net trochstjoerd oer in rûte tunnel, en in rûte foar de groep is net genôch sûnder in multicast-bewuste paad of in reflektor op 'e LAN.