Privat DNS-namn eller bara en IP? Bestäm innan du delar det

Två frågor blandas ihop när en privat tjänst öppnas för fjärranvändare. Den första är vilket namn klienterna ska använda; den andra är vilka källor tjänsten ska tillåta. Svara på dem i den ordningen, för ett korrekt namn bakom en felaktig åtkomstregel misslyckas ändå, och en korrekt regel bakom ett namn som inte slås upp testas aldrig.

Villkor ett: vilken resolverväg har klienterna?

Ett privat namn fungerar bara om klientens resolver kan svara på det. Det betyder att en auktoriserad fjärrklient måste nå en DNS-server som håller zonen, antingen genom tunneln eller genom en resolver som organisationen redan kör för fjärranvändare. Tunneln är en transport, inte en katalog. Den ger klienten en väg till en resolver, och den berättar inte för klienten vilken zon den ska fråga efter.

resolvectl query files.corp.example
dig @10.20.30.10 +short files.corp.example

En offentlig resolver lär sig inte en privat zon bara för att laptopen är ansluten till ett VPN.

Suffixet förtjänar samma uppmärksamhet. Använd en underdomän till en domän som organisationen kontrollerar, så att ägarskap och certifikatplanering förblir tydliga. Undvik .local: specifikationen för multicast DNS binder det suffixet till link-local-uppslag, och en routad tunnel återskapar inte det beteendet åt dig.

Villkor två: vilken källa tar tjänsten emot?

Åtkomstregler skrivs mot adresser, så den användbara frågan är vilken adress tjänsten ser efter routning och översättning. För en exempeltjänst på 10.20.30.40 kommer kontorsklienter från 10.20.30.0/24 och fjärrklienter från en separat pool som 10.99.0.0/24.

Om en gateway översätter fjärrpoolen ser tjänsten översättaren, och en regel skriven för 10.99.0.0/24 kommer inte att stämma.

Läs detta från tjänstens sida i stället för klientens sida. En lyssnarlogg eller en paketinsamling på tjänstevärden visar källan som faktiskt kom fram; klientens egen adress är bara en gissning om vad som överlevde vägen.

Villkor tre: är namnet knutet till en tjänst eller till en värd?

Ett namn som pekar på adressen till en maskin knyter varje klient till den maskinen. Ett namn som pekar på en lastbalanserare eller en stabil tjänstadress överlever byte av värden bakom den. Välj medvetet, för att ändra detta senare innebär att ändra varje klients bokmärken och varje certifikats ämne.

För en enda intern tjänst är en direktpost vanligtvis bra och enklare att tänka igenom.

För allt som ska bytas ut, byggas om eller skalas är en stabil front end värd den extra konfigurationen. Testet är enkelt: om du kan byta ut backend utan att berätta det för användarna är namnet knutet till tjänsten; om inte är det knutet till en värd.

Testa de två besluten var för sig

Slå upp först och anslut sedan. Ett uppslagstest som returnerar den förväntade adressen bevisar namnvägen och säger ingenting om åtkomst. Ett anslutningstest bevisar vägen och regeln tillsammans, så kör det först efter att uppslaget har lyckats.

curl -sv --max-time 5 https://files.corp.example/health

Testa sedan en förbjuden källa en gång, och anteckna resultatet.

Håll de två posterna åtskilda i din dokumentation: namnet och dess zon, de tillåtna källorna och regelns ägare. När den ena ändras behöver den andra inte ändras.

Där beslutet brukar gå fel

Det vanliga felet är en tjänst som publiceras under ett namn som bara slås upp på kontorsnätet, med en åtkomstregel som bara tillåter kontorsintervallet. Fjärranvändare rapporterar då en trasig tjänst som i själva verket är två separata utelämnanden. Det andra vanliga felet är det omvända: en bred åtkomstregel som lagts till för att få bort ett namnproblem lämnar tjänsten nåbar från källor som ingen avsåg. Båda är konfigurationsutelämnanden, och från användarens stol ser de likadana ut.

Inget av felen syns från ett enda lyckat test. Därför förtjänar de två besluten separata poster och separata tester, även när samma person fattar båda.

Skriv ned båda innan tjänsten går i drift, för nästa ändring blir lättare att tänka igenom. Posten är kort: en rad för namnet och dess zon, en rad för de tillåtna källorna och regelns ägare.