Miksi SRV-tietue auttaa vain asiakasta, joka itse kysyy sitä

SRV-tietueen lisääminen vyöhykkeeseesi ei opeta yhtään VPN-asiakasta hakemaan sitä. Asiakkaan on tunnettava tunniste, päätettävä lähettää kysely ja toimittava sen mukaan, mitä takaisin tulee, eikä DNS voi tarjota kahta ensimmäistä näistä. Siksi useimmat epäonnistuneet SRV-suunnitelmat ovat asiakasongelmia DNS-asussa. Lue ensin asiakkaan löytämiskäyttäytyminen ja julkaise sitten vain se tunniste, jota se todella kysyy.

Tietue, jota kukaan ei kysy, ei voi auttaa ketään

SRV julkaisee palvelun sijainnin; se ei ilmoita palvelua. Mikään ei työnnä tietuetta asiakasta kohti, eikä mikään ratkaisija tarjoa nimeä, jota ei koskaan kysytty. Haku alkaa siitä, että sovellus päättää tehdä sen, joten tunnisteen on tultava tuotteen dokumentaatiosta tai ohjelmiston tarkkailusta verkossa. Siellä missä asiakkaalla ei ole löytämisvaihetta, tietue muuttaa vyöhykettä eikä mitään muuta.

Siksi yksi tuote verkossa voi alkaa toimia, kun taas toinen ei kärsi samasta muutoksesta. Muuttuja on ohjelmisto, ja DNS-palvelin tekee täsmälleen sen, mitä sille sanottiin. Lue vyöhyke uudelleen myös muokkauksen jälkeen, sillä väärin kirjoitettu tunniste piiloutuu helposti tietueiden joukkoon, jotka kaikki näyttävät samoilta.

Lue kentät ennen kuin kirjoitat ne

Tietue kantaa neljä arvoa, ja jokainen vastaa eri kysymykseen: prioriteetti järjestää kohteet, joita asiakas voi kokeilla, paino jakaa kuorman saman prioriteetin kohteiden kesken, portti nimeää kuljetusportin ja kohde nimeää isännän. Määritelmä sallii myös kohteen . tarkoittavan, että palvelu on tarkoituksella pois käytöstä, mikä on hyödyllinen vastaus eikä rikkinäinen.

Mikään näistä kentistä ei kanna tunnistetietoja, varmennekäytäntöä tai sovellusversiota, ja painon sivuuttava asiakas yhdistää silti, vain ilman aiottua tasapainoa. Kohde tarvitsee omat osoitetietueensa, ja sen pitäisi olla kanoninen nimi eikä alias. Tietueen julkaiseminen, joka osoittaa isäntään ilman kuuntelijaa, tuottaa yhteysvirheen, joka luetaan DNS-viaksi, ja se on kallein harhaanjohtamisen muoto. Julkaise koko ketju tai ei mitään siitä.

Selvitä tunniste, jonka asiakas todella lähettää

Määritä tunniste todisteista, ei arvauksesta tuotteen nimestä. Joko dokumentaatio ilmoittaa palvelun nimen tai kaappaus näyttää kyselyn, joka lähtee asiakkaasta sen käynnistyessä. Molemmat reitit päättyvät samaan paikkaan: tarkka nimi ja tyyppi testattavaksi ratkaisijaa vasten.

dig +short SRV _vpn._tcp.gw.example
dig +short A edge2.gw.example
tcpdump -ni any udp port 53

Vertaa vastausta julkaisemaasi tietueeseen merkki merkiltä, sillä alaviivat ja loppupiste ovat osa nimeä. Tyhjä vastaus kyselyyn, joka todella lähetettiin, osoittaa vyöhykkeeseen, kun taas kyselyn täydellinen puuttuminen osoittaa asiakkaaseen, ja nämä havainnot lähettävät sinut eri tiimien luo. Todellinen vastaus näyttää alla olevalta riviltä, jossa prioriteetti 20 häviää mille tahansa alemman prioriteetin tietueelle ja asiakas valitsee portin 8443 nimetyltä kohteelta.

_vpn._tcp.gw.example. 600 IN SRV 20 10 8443 edge2.gw.example.

Myös kohteen on oltava olemassa

Ratkeava kohde ei ole sama kuin vastaava palvelu. Tarkista kohteen osoitetietueet ja tarkista sitten, että jotain kuuntelee julkaistulla portilla ja protokollalla. TCP-tietue, joka osoittaa vain UDP-kuuntelijaan, on ristiriita, jota mikään vyöhykkeen muokkaus ei korjaa. Pidä TTL lyhyenä, kun kohde on liikkeessä, ja pidennä sitä, kun nimi lakkaa liikkumasta.

Asiakkaat, jotka todella toteuttavat löytämisen, eroavat siinä, kuinka paljon tietueesta ne ottavat huomioon. Jotkut käyttävät vain prioriteettia, jotkut pitävät painoa neuvoa-antavana ja harvat sivuuttavat portin ja olettavat oletusarvon. Nämä erot kuuluvat muistiinpanoihisi tunnisteen viereen, sillä ne selittävät käyttäytymistä, joka muuten näyttää ratkaisijan vialta.

Löytäminen ei ole todennus

SRV-vastaus kertoo, mihin yhdistää, eikä se kerro mitään siitä, keneen luottaa perille päästyä. Jätä asiakkaan varmenteen validointi ja palvelimen identiteetin tarkistukset täsmälleen sellaisiksi kuin ne olivat, sillä tietue, jonka joku muu voi väärentää, ei saisi tulla luottamuspäätökseksi. DNS-vastaukset ovat välimuistiin tallennettavia ja vyöhykettä hallitsevan muokattavissa, mikä tekee niistä huonon paikan käytännön koodaamiseen.

Asiakkaalle, jolla ei ole löytämistukea, jaa profiili tai yhdyskäytävän URL-osoite, jonka se hyväksyy, ja kirjaa, mikä tuote käyttää mitä menetelmää. Tämä merkintä estää seuraavaa ylläpitäjää lisäämästä tietuetta ja odottamasta, että se toimisi kaikkialla. SRV-määritelmä kuvaa kohteiden välistä valintaa, ja sen lukeminen valtuutusmekanismina on se tapa, jolla hyödyllisestä tietueesta tulee turvallisuusolettama. Julkaise tarkoituksella, nimeä tunniste dokumentaatiossasi ja kohtele asiakasta komponenttina, joka päättää, onko millään tällä merkitystä.