Kvifor ein SRV-post berre hjelper ein klient som sjølv slår han opp

Å leggje ein SRV-post til sona di lærer ingen VPN-klient å slå han opp. Klienten må kjenne namnet, bestemme seg for å sende spørjinga og handle på det som kjem tilbake, og DNS kan ikkje levere dei to første. Difor er dei fleste mislukka SRV-planane klientproblem i DNS-kostyme. Les oppdagingåtferda til klienten først, og publiser deretter berre namnet han faktisk slår opp.

Ein post ingen slår opp, kan ikkje hjelpe nokon

SRV publiserer plasseringa til ei teneste; han annonserer henne ikkje. Ingenting skuvar ein post mot ein klient, og ingen resolver tilbyr eit namn som aldri vart spurt om. Oppslaget byrjar når applikasjonen bestemmer seg for å gjere det, så namnet må kome frå dokumentasjonen til produktet eller frå å observere programvara på nettet. Der klienten ikkje har noko oppdagingstrinn, endrar ein post sona og ingenting anna.

Difor kan eitt produkt på eit nett byrje å verke medan eit anna ikkje blir påverka av den same endringa. Variabelen er programvara, og DNS-tenaren gjer nøyaktig det han fekk beskjed om. Les sona tilbake etter redigeringa òg, fordi eit feilskrive namn lett gøymer seg blant postar som alle ser like ut.

Les felta før du skriv dei

Ein post ber fire verdiar, og kvar av dei svarar på eit ulikt spørsmål: prioritet ordnar måla ein klient kan prøve, vekt fordeler lasta mellom mål med lik prioritet, port namngjev transportporten, og mål namngjev verten. Spesifikasjonen tillèt òg eit mål på . for å bety at tenesta med vilje ikkje er tilgjengeleg, noko som er eit nyttig svar og ikkje eit øydelagt eit.

Ingen av desse felta ber påloggingsinformasjon, ein sertifikatpolicy eller ein applikasjonsversjon, og ein klient som ignorerer vekt koplar framleis til, berre utan den tilsikta balansen. Målet treng eigne adressepostar, og det bør vere eit kanonisk namn framfor eit alias. Å publisere ein post som peikar på ein vert utan lyttar gir ein tilkoplingfeil som blir lesen som ein DNS-feil, og det er den dyraste forma for villleiing. Publiser heile kjeda eller ingenting av henne.

Finn namnet klienten faktisk sender

Fastset namnet ut frå bevis i staden for ei gjetting om namnet til produktet. Anten oppgir dokumentasjonen tenestenamnet, eller så viser eit opptak spørjinga som forlèt klienten når han startar. Begge vegar endar på same stad: eit nøyaktig namn og ein type å teste mot resolvaren.

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

Samanlikn svaret med posten du publiserte, teikn for teikn, fordi understrekane og punktumet til slutt er ein del av namnet. Eit tomt svar på ei spørjing som faktisk vart send, peikar på sona, medan inga spørjing i det heile peikar på klienten, og desse funna sender deg til ulike team. Eit ekte svar ser ut som linja nedanfor, der prioritet 20 taper mot ein kvar post med lågare prioritet, og klienten ringjer port 8443 på det namngjevne målet.

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

Målet må òg finnast

Eit mål som blir løyst opp, er ikkje det same som ei teneste som svarar. Kontroller adressepostane for målet, og kontroller deretter at noko lyttar på den publiserte porten og protokollen. Ein TCP-post som peikar på ein lyttar som berre er UDP, er eit misforhold som inga soneendring reparerer. Hald TTL kort medan målet er i rørsle, og forleng han når namnet sluttar å flytte seg.

Klientar som faktisk implementerer oppdaging, varierer i kor mykje av posten dei respekterer. Nokre brukar berre prioritet, nokre behandlar vekt som rådgjevande, og eit par ignorerer porten og tek ein standard. Desse skilnadane høyrer heime i notata dine ved sida av namnet, fordi dei forklarer åtferd som elles ser ut som ein resolverfeil.

Oppdaging er ikkje autentisering

Eit SRV-svar seier kvar du skal kople til, og det seier ingenting om kven du skal stole på når du kjem fram. Lat sertifikatvalideringa og serveridentitetssjekkane til klienten vere nøyaktig som dei var, fordi ein post som andre kan forfalske, bør ikkje bli ei tillitsavgjerd. DNS-svar kan bufrst og redigerast av den som kontrollerer sona, noko som gjer dei til ein dårleg stad å kode policy i.

For ein klient utan oppdagingstøtte, distribuer profilen eller gateway-URL-en han godtek, og noter kva produkt som brukar kva metode. Den notata hindrar den neste administratoren i å leggje til ein post og vente at han verkar overalt. SRV-spesifikasjonen skildrar valet mellom mål, og å lese han som ein autorisasjonsmekanisme er måten ein nyttig post blir ei sikkerheitsføresetnad. Publiser med vilje, namngi namnet i dokumentasjonen din, og handsam klienten som komponenten som avgjer om noko av dette betyr noko.