Miksi nimikyselyt epäonnistuvat reititetyssä OpenVPN-tunnelissa

Isäntä vastaa pingiin osoitteella ja epäonnistuu jokaisessa nimihaussa. Tunneli on ylhäällä ja reitti on olemassa, joten luonteva johtopäätös on, että VPN on väärin määritetty. Hyödyllisempi johtopäätös on, että haku ei koskaan ollut reititettävissä: reititetty tunneli kuljettaa unicast-IP:tä, kun taas kysely oli broadcast, joka etsi segmenttiä, jota toisella puolella ei ole. Heti kun kerrosten epäsuhta tulee näkyviin, korjaukset järjestyvät itsestään kustannuksen mukaan.

Myytti: tunneli on rikki, koska nimet epäonnistuvat

Oire on vakuuttava, koska kaikki nimitason yläpuolella toimii. Osoitteet reitittyvät, rajapinta on ylhäällä ja vastapuoli vastaa pingiin. Epäonnistui löytömekanismi, jolla ei koskaan ollut polkua pistepisteyhteyden yli, ja se on eri väite kuin rikki mennyt tunneli. Näiden kahden väitteen erottaminen on suurin osa diagnoosista.

Sen käsitteleminen tunnelin vikana johtaa profiilimuutoksiin, jotka eivät voi auttaa. Vaihtoehtojen lisääminen, salauksen vaihtaminen tai asiakkaan uudelleenasennus jättää broadcastin täsmälleen sinne, missä se oli.

Nimeä epäonnistunut mekanismi ennen kuin nimeät korjauksen. Broadcastia käyttävä haku tarvitsee segmentin, kun taas ratkaisijaa käyttävä haku tarvitsee osoitteen, jolta kysyä.

Mitä TUN kuljettaa ja mitä ei

TUN-laite on IP-rajapinta, ja juuri se tekee siitä reititettävän. OpenVPN antaa asiakkaalle osoitteen ja joukon reittejä, ja siitä lähtien asiakas lähettää datagrammeja vastapuolelle. Mikään siinä mallissa ei luo jaettua yhteyttä, jossa jokainen isäntä kuulee jokaisen kehyksen.

Löytöliikenne ei sovi siihen malliin lainkaan. Vanhemmat Windowsin nimikyselyt, SSDP-ilmoitukset ja mDNS-pyynnöt lähetetään kaikille segmentissä eikä yhdelle kohteelle. Reititetyllä yhteydellä ei ole «kaikkia», jolle lähettää. Jokainen noista mekanismeista olettaa jaetun välineen.

Tunneli voi siis olla terve, kun taas löytö epäonnistuu täysin. Juuri siitä lauseesta on pidettävä kiinni, kun joku ilmoittaa VPN:n olevan alhaalla.

Sillaus toimii poistamalla rajan

TAP-laite kuljettaa kehyksiä, ja silta liittää sen todelliseen LAN-segmenttiin. Silloin asiakkaalla on osoite siinä segmentissä ja se kuulee sen broadcast-liikennettä. Siksi sillaus näyttää parantavan nimen ongelman. Se tekee asiakkaasta myös riippuvaisen siitä segmentistä osoitteistuksessa.

Parannus on reititysrajan poistaminen, ei mikään uusi nimeämiskyky tunnelin sisällä. Kaikki, mitä segmentti lähettää broadcastina, ylittää nyt myös yhteyden.

Pienelle laboratoriolle se on reilu vaihtokauppa. Hajautetulle työvoimalle harvoin.

DNS:n ja WINS:n työntäminen on kapeampi korjaus

Anna asiakkaalle tietty paikka kysyä. dhcp-option DNS ja dhcp-option DOMAIN ohjaavat sisäiset nimet palvelimelle, joka tuntee vyöhykkeen, ja NetBIOSiin yhä nojaava Windows-asiakas voi saada WINS-palvelimen samalla tavalla. Tunneli pysyy reititettynä ja segmentti pysyy siellä, mihin se kuuluu.

Kaksi ehtoa ratkaisee, toimiiko se. Nimetyn palvelimen on vastattava vyöhykkeestä, ja kysely on sallittava tunnelin läpi.

Testaa ratkaisija asiakkaalta, älä palvelimen omasta kuoresta. Paikallisesti toimiva ratkaisija ei kerro mitään siitä, mitä tunneli kuljettaa.

Selvitä, mikä kerros epäonnistui

Pingaa ensin osoitetta, sitten ratkaise nimi ja lue, mikä palvelin vastasi. Kielteinen vastaus palvelimelta, joka ei isännöi vyöhykettä, näyttää erilaiselta kuin kysely, joka ei koskaan lähtenyt koneesta. Nimi, joka ratkeaa mutta hylkää yhteydet, on kokonaan kolmas ongelma.

Multicast on saman muurin takana. Ryhmää kuten 224.0.0.251 ei välitetä reititetyn tunnelin yli oletuksena, eikä ryhmän reitti riitä ilman multicastin ymmärtävää polkua tai heijastinta LANissa.