Hvorfor en SRV-post bare hjelper en klient som selv slår den opp

Å legge en SRV-post til sonen din lærer ingen VPN-klient å slå den opp. Klienten må kjenne navnet, bestemme seg for å sende spørringen og handle på det som kommer tilbake, og DNS kan ikke levere de to første. Derfor er de fleste mislykkede SRV-planer klientproblemer i DNS-kostyme. Les klientens oppdagelsesatferd først, og publiser deretter bare navnet den faktisk slår opp.

En post ingen slår opp, kan ikke hjelpe noen

SRV publiserer plasseringen til en tjeneste; den annonserer den ikke. Ingenting skyver en post mot en klient, og ingen resolver tilbyr et navn som aldri ble spurt om. Oppslaget begynner når applikasjonen bestemmer seg for å gjøre det, så navnet må komme fra produktets dokumentasjon eller fra å observere programvaren på nettet. Der klienten ikke har noe oppdagelsestrinn, endrer en post sonen og ingenting annet.

Derfor kan ett produkt på et nett begynne å virke mens et annet ikke påvirkes av den samme endringen. Variabelen er programvaren, og DNS-tjeneren gjør nøyaktig det den fikk beskjed om. Les sonen tilbake etter redigeringen også, fordi et feilskrevet navn lett skjuler seg blant poster som alle ser like ut.

Les feltene før du skriver dem

En post bærer fire verdier, og hver av dem svarer på et forskjellig spørsmål: prioritet ordner målene en klient kan prøve, vekt fordeler lasten mellom mål med lik prioritet, port navngir transportporten, og mål navngir verten. Spesifikasjonen tillater også et mål på . for å bety at tjenesten bevisst er utilgjengelig, noe som er et nyttig svar og ikke et ødelagt et.

Ingen av disse feltene bærer påloggingsinformasjon, en sertifikatpolicy eller en applikasjonsversjon, og en klient som ignorerer vekt kobler fortsatt til, bare uten den tilsiktede balansen. Målet trenger egne adresseposter, og det bør være et kanonisk navn fremfor et alias. Å publisere en post som peker på en vert uten lytter gir en tilkoblingsfeil som leses som en DNS-feil, og det er den dyreste formen for villedning. Publiser hele kjeden eller ingenting av den.

Finn navnet klienten faktisk sender

Fastslå navnet ut fra bevis i stedet for en gjetning om produktets navn. Enten oppgir dokumentasjonen tjenestenavnet, eller så viser en opptak spørringen som forlater klienten når den starter. Begge veier ender på samme sted: et nøyaktig navn og en type å teste mot resolveren.

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

Sammenlign svaret med posten du publiserte, tegn for tegn, fordi understrekene og punktumet til slutt er en del av navnet. Et tomt svar på en spørring som faktisk ble sendt, peker på sonen, mens ingen spørring i det hele tatt peker på klienten, og disse funnene sender deg til forskjellige team. Et ekte svar ser ut som linjen nedenfor, der prioritet 20 taper mot enhver post med lavere prioritet, og klienten ringer port 8443 på det navngitte målet.

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

Målet må også finnes

Et mål som løses opp, er ikke det samme som en tjeneste som svarer. Kontroller adressepostene for målet, og kontroller deretter at noe lytter på den publiserte porten og protokollen. En TCP-post som peker på en lytter som bare er UDP, er et misforhold som ingen soneendring reparerer. Hold TTL kort mens målet er i bevegelse, og forleng det når navnet slutter å flytte seg.

Klienter som faktisk implementerer oppdagelse, varierer i hvor mye av posten de respekterer. Noen bruker bare prioritet, noen behandler vekt som rådgivende, og et par ignorerer porten og antar en standard. Disse forskjellene hører hjemme i notatene dine ved siden av navnet, fordi de forklarer atferd som ellers ser ut som en resolverfeil.

Oppdagelse er ikke autentisering

Et SRV-svar sier hvor du skal koble til, og det sier ingenting om hvem du skal stole på når du ankommer. La klientens sertifikatvalidering og serveridentitetssjekker være nøyaktig som de var, fordi en post som andre kan forfalske, ikke bør bli en tillitsbeslutning. DNS-svar kan bufres og redigeres av den som kontrollerer sonen, noe som gjør dem til et dårlig sted å kode policy i.

For en klient uten oppdagelsesstøtte, distribuer profilen eller gateway-URL-en den godtar, og noter hvilket produkt som bruker hvilken metode. Det notatet hindrer den neste administratoren i å legge til en post og forvente at den virker overalt. SRV-spesifikasjonen beskriver valget mellom mål, og å lese den som en autorisasjonsmekanisme er måten en nyttig post blir en sikkerhetsantakelse. Publiser bevisst, navngi navnet i dokumentasjonen din, og behandle klienten som komponenten som avgjør om noe av dette betyr noe.