Hvers vegna nafnaleitir mistakast um beina OpenVPN-göng

Hýsill svarar ping eftir vistfangi og mistekst í hverri leit eftir nafni. Göngin eru uppi og leiðin er til, svo eðlileg niðurstaða er að VPN-ið sé rangt stillt. Gagnlegri niðurstaða er að leitin hafi aldrei verið beinanleg: bein göng flytja unicast IP, en fyrirspurnin var útvarp sem leitaði að sneið sem er ekki til hinum megin. Um leið og misræmi laganna verður sýnilegt raða lagfæringarnar sér sjálfar eftir kostnaði.

Goðsögn: göngin eru biluð því nöfnin mistakast

Einkennin sannfæra því allt fyrir ofan nafnalagið virkar. Vistföng eru beinuð, viðmótið er uppi og jafninginn svarar ping. Það sem mistókst er uppgötvunaraðferð sem hafði aldrei slóð um punkt-til-punkt tengingu, og það er önnur fullyrðing en biluð göng. Að aðskilja þessar tvær fullyrðingar er stærsti hluti greiningarinnar.

Ef þetta er meðhöndlað sem bilun í göngunum leiðir það til sniðbreytinga sem geta ekki hjálpað. Að bæta við valkostum, skipta um dulkóðun eða setja upp biðlarann aftur skilur útvarpið nákvæmlega þar sem það var.

Nefndu aðferðina sem mistókst áður en þú nefnir lagfæringuna. Leit sem notar útvarp þarf sneið, en leit sem notar leysir þarf vistfang til að spyrja.

Hvað TUN flytur og hvað ekki

TUN-tæki er IP-viðmót, og það er það sem gerir það beinanlegt. OpenVPN gefur biðlaranum vistfang og mengi leiða, og þaðan í frá sendir biðlarinn gagnagramma til jafnings. Ekkert í þeirri fyrirmynd býr til sameiginlega tengingu þar sem hver hýsill heyrir hverja ramma.

Uppgötvunarumferð passar alls ekki í þá fyrirmynd. Eldri nafnfyrirspurnir Windows, SSDP-tilkynningar og mDNS-beiðnir eru sendar til allra á sneið í stað eins áfangastaðar. Bein tenging hefur engan «alla» til að senda til. Hver þessara aðferða gerir ráð fyrir sameiginlegum miðli.

Göngin geta því verið heilbrigð á meðan uppgötvun mistekst algjörlega. Það er setningin sem halda skal í þegar einhver tilkynnir að VPN-ið sé niðri.

Brúun virkar með því að fjarlægja mörkin

TAP-tæki flytur ramma, og brú tengir það við raunverulega LAN-sneið. Biðlarinn hefur þá vistfang á þeirri sneið og heyrir útvarpsumferð hennar. Þess vegna virðist brúun lækna nafnavandann. Hún gerir biðlarann líka háðan þeirri sneið fyrir vistfangsgjöf.

Lækningin er að fjarlægja beiningarmörkin, ekki einhver ný nafngeta inni í göngunum. Allt sem sneiðin útvarpar fer nú líka yfir tenginguna.

Fyrir litla tilraunastofu er þetta sanngjarnt skipti. Þvert á dreifðan vinnumarka er það sjaldgæft.

Að ýta DNS og WINS út er þrengri lagfæringin

Að ýta DNS og WINS út er þrengri lagfæringin. dhcp-option DNS og dhcp-option DOMAIN beina innri nöfnum að þjóni sem þekkir svæðið, og Windows-biðlari sem enn treystir á NetBIOS getur fengið WINS-þjón á sama hátt. Göngin haldast bein og sneiðin heldur sér á sínum stað.

Tvö skilyrði ráða því hvort þetta virkar. Nefndi þjónninn verður að svara fyrir svæðið, og fyrirspurnin verður að vera leyfð um göngin.

Prófaðu leysinn frá biðlaranum frekar en úr skel þjónsins sjálfs. Leysir sem virkar á staðnum segir ekkert um það sem göngin flytja.

Finndu út hvaða lag mistókst

Pingaðu vistfangið fyrst, leystu síðan nafnið og lestu hvaða þjónn svaraði. Neikvætt svar frá þjóni sem hýsir ekki svæðið lítur öðruvísi út en fyrirspurn sem fór aldrei af vélinni. Nafn sem leysist en hafnar tengingum er algjörlega þriðja vandamálið.

Multicast er handan sama veggs. Hópur eins og 224.0.0.251 er ekki sendur um bein göng sjálfgefið, og leið fyrir hópinn nægir ekki án slóðar sem skilur multicast eða endurkasts á LAN-inu.