Hvorfor en SRV-post kun hjælper en klient, der selv slår den op

At tilføje en SRV-post til din zone lærer ikke nogen VPN-klient at slå den op. Klienten skal kende navnet, beslutte at sende forespørgslen og handle på det, der kommer tilbage, og DNS kan ikke levere de første to af disse. De fleste mislykkede SRV-planer er derfor klientproblemer i DNS-kostume. Læs først klientens opdagelsesadfærd, og offentliggør derefter kun det navn, den faktisk slår op.

En post, som ingen slår op, kan ikke hjælpe nogen

SRV offentliggør placeringen af en tjeneste; den annoncerer den ikke. Intet skubber en post mod en klient, og ingen resolver tilbyder et navn, der aldrig blev spurgt om. Opslaget begynder, når applikationen beslutter at gøre det, så navnet skal komme fra produktets dokumentation eller fra at iagttage softwaren på netværket. Hvor klienten ikke har et opdagelsestrin, ændrer en post zonen og intet andet.

Derfor kan ét produkt på et netværk begynde at virke, mens et andet ikke påvirkes af den samme ændring. Variablen er softwaren, og DNS-serveren gør præcis, hvad den fik besked om. Læs zonen tilbage efter redigeringen, fordi et fejlskrevet navn let skjuler sig blandt poster, der alle ser ens ud.

Læs felterne, før du skriver dem

En post bærer fire værdier, og hver af dem svarer på et forskelligt spørgsmål: prioritet ordner de mål, en klient kan prøve, vægt fordeler belastningen mellem mål med samme prioritet, port angiver transportporten, og mål angiver værten. Specifikationen tillader også et mål på . til at betyde, at tjenesten bevidst er utilgængelig, hvilket er et nyttigt svar og ikke et ødelagt et.

Ingen af disse felter bærer legitimationsoplysninger, en certifikatpolitik eller en applikationsversion, og en klient, der ignorerer vægt, forbinder stadig, blot uden den tilsigtede balance. Målet har brug for sine egne adresseposter, og det bør være et kanonisk navn frem for et alias. Offentliggørelse af en post, der peger på en vært uden lytter, giver en forbindelsesfejl, der læses som en DNS-fejl, og det er den dyreste form for vildledning. Offentliggør hele kæden eller intet af den.

Find det navn, klienten faktisk sender

Fastslå navnet ud fra beviser i stedet for en gætten på produktets navn. Enten angiver dokumentationen tjenestenavnet, eller også viser en optagelse den forespørgsel, der forlader klienten, når den starter. Begge veje ender samme sted: et præcist navn og en type at teste mod resolverserveren.

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

Sammenlign svaret med den post, du offentliggjorde, tegn for tegn, fordi understregningerne og punktummet til sidst er en del af navnet. Et tomt svar på en forespørgsel, der faktisk blev sendt, peger på zonen, mens ingen forespørgsel overhovedet peger på klienten, og de fund sender dig til forskellige teams. Et rigtigt svar ser ud som linjen nedenfor, hvor prioritet 20 taber til enhver post med lavere prioritet, og klienten ringer til port 8443 på det navngivne mål.

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

Målet skal også eksistere

Et mål, der opløses, er ikke det samme som en tjeneste, der svarer. Kontrollér adresseposterne for målet, og kontrollér derefter, at noget lytter på den offentliggjorte port og protokol. En TCP-post, der peger på en lytter, der kun er UDP, er en uoverensstemmelse, som ingen zoneændring reparerer. Hold TTL kort, mens målet er i bevægelse, og forlæng det, når navnet holder op med at flytte sig.

Klienter, der faktisk implementerer opdagelse, varierer i, hvor meget af posten de respekterer. Nogle bruger kun prioritet, nogle behandler vægt som rådgivende, og et par ignorerer porten og antager en standard. De forskelle hører til i dine noter ved siden af navnet, fordi de forklarer adfærd, som ellers ser ud som en resolverfejl.

Opdagelse er ikke autentificering

Et SRV-svar siger, hvor du skal forbinde, og det siger intet om, hvem du skal stole på, når du ankommer. Hold klientens certifikatvalidering og serveridentitetstjek nøjagtigt, som de var, fordi en post, som andre kan forfalske, ikke bør blive en tillidsbeslutning. DNS-svar kan cachelagres og redigeres af den, der kontrollerer zonen, hvilket gør dem et dårligt sted at kode politik i.

Til en klient uden opdagelsesstøtte skal du distribuere den profil eller gateway-URL, den accepterer, og notere, hvilket produkt der bruger hvilken metode. Den note forhindrer den næste administrator i at tilføje en post og forvente, at den virker overalt. SRV-specifikationen beskriver valget mellem mål, og at læse det som en autorisationsmekanisme er, hvordan en nyttig post bliver en sikkerhedsantagelse. Offentliggør bevidst, navngiv feltet i din dokumentation, og behandl klienten som den komponent, der afgør, om noget af det betyder noget.