VPN-endepunktnamn kontra namn på privat teneste: to eigarar

To namn kan skildre same filial og svare på heilt ulike spørsmål. vpn.branch.example fortel ein ekstern part kvar VPN-endepunktet finst, og det må løysast opp før nokon tunnel finst. inventory.branch.example fortel ein autorisert brukar kvar ein privat applikasjon bur, og det har først tyding når tunnelen er oppe. Vedlikehald av det eine gjer ingenting for det andre.

Namngi dei to oppføringane før du feilsøkjer nokon av dei

Skriv ned begge saman med eigarane deira. For endepunktet, noter kven som oppdaterer den offentlege adressa og korleis VPN-klienten fornyar svaret sitt. For tenesta, noter kven som eig den private adressa, kva sone som held oppføringa og kva resolverar som skal svare for henne.

Den korte lista hindrar den vanlegaste feildiagnosen på området: å starte ein fungerande filialtunnel på nytt for å reparere ei oppføring som berre lever inne i han. Tunnelen er transporten for tenestenamnet; han er ikkje autoriteten for det.

Når ei endring blir føreslått, spør kva av dei to oppføringane ho rører. Viss ingen kan svare, er endringa ikkje klar til planlegging.

Endepunktet må løysast opp før nokon tunnel finst

Anta at internettilkoplinga til filialen får ei ny offentleg adresse. Endepunktsoppdateraren publiserer den nye adressa, og den eksterne VPN-implementasjonen må kunne lese det endra svaret. Kva resolver som enn leverer svaret, må han vere tilgjengeleg utan tunnelen, elles jagar klienten eit namn han berre kan løyse opp etter å ha kopla til det han ikkje finn.

Den oppstartsavhengigheita er verdt å seie rett ut, fordi ho lett oppstår ved eit uhell når alle interne resolverar sit bak VPN-en. Hald ein sti før tunnelen for endepunktoppslaget, og stadfest gjenoppkoplingåtferda til klienten i staden for å anta at eit nytt svar blir plukka opp med ein gong.

Dynamisk DNS har også grenser som oppføringsoppdateringa ikkje kan krysse. Oppdatering av ei oppføring opnar ingen brannmurport, lagar ingen NAT-mapping og provar ingen part-identitet. Ei publisert adresse med lukka port gir ein klient som løyser opp rett og framleis ikkje kan kopie til noko.

Til slutt kan ein køyrande klient halde fram med å bruke eit bufra endepunkt til han koplar til på nytt. Skil publisering, buffer og gjenoppkoplingpolicy i notata dine, slik at ein utdatert part ikkje blir forveksla med ein defekt oppdaterar.

Tenestenamnet skildrar kvar applikasjonen bur

Anta no at tunnelen held seg sunn, men at inventarserveren flyttar frå 172.26.14.20 til 172.26.14.35. Den offentlege endepunktoppføringa er upåverka, medan den private tenesteoppføringa må endrast. Bruk av ei adresse reservert for den tenesta, eller ei statisk tildeling, gjer dette sjeldnare; ein autorisert oppdateringssti handterer gongene det er meint.

To oppdateringsmekanismar blir blanda saman her. RFC 2136 definerer ein protokoll for å leggje til og slette DNS-oppføringar i ei sone, medan ein kommersiell leverandør av dynamisk DNS kan eksponere eit heilt anna HTTP-API for eit anna føremål. Bruk av det eine tyder ikkje at det andre finst i miljøet ditt. Sjekk kva mekanisme sona di faktisk godtek før du skriv ein oppdaterar mot henne.

Eit korrekt privat svar er berre den første føresetnaden. For at ein ekstern kallar skal kunne bruke det, treng klienten ein resolver som fører den private sona, ein policy som tillèt spørjingar til den resolveren, og vidaresending for adressa som kjem tilbake. Eit namn som løyser opp til ei adresse klienten ikkje kan nå, gir ein tidsavbrot som ser ut som ein serverfeil.

Test dei to stiane kvar for seg

Sjekk endepunktet frå utsida av tunnelen og tenesta frå innsida, og hald resultata som to uavhengige faktum:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

Viss den første spørjinga feilar, er problemet offentleg publisering eller oppløysingsstien før tunnelen, og inga intern endring vil hjelpe. Viss den andre returnerer ei adresse men den tredje ikkje viser nokon rute gjennom tunnelen, er DNS-laget i orden og vidaresendingspolicyen er det ikkje.

Køyr paret etter kvar adresseendring, og noter kva oppføring som flytta seg. Ei overlevering som berre seier «DNS vart oppdatert», lèt den neste ingeniøren gjete kva av dei to livssyklusane som faktisk køyrde.