Namme fan VPN-einpunt tsjin namme fan partikuliere tsjinst: twa eigners
It iepenbiere VPN-einpunt en de namme fan in partikuliere tsjinst feroarje om ferskillende redenen. Jou elk syn eigen bywurkings-eigner, resolverpaad en berikberens-kontrôle.
Twa nammen kinne deselde filiale beskriuwe en folslein ferskillende fragen beantwurdzje. vpn.branch.example fertelt in ôfstân-pear wêr’t it VPN-einpunt te finen is, en it moat oplost wurde foardat der hokker tunnel dan ek bestiet. inventory.branch.example fertelt in autorisearre brûker wêr’t in partikuliere applikaasje wennet, en it is pas fan belang as de tunnel stiet. It ûnderhâlden fan ien docht neat foar de oare.
Nammje beide records foardat jo ien fan beide debugge
Skriuw beide op mei har eigners. Foar it einpunt, notearje wa’t it iepenbiere adres bywurket en hoe’t de VPN-klient syn antwurd fernijt. Foar de tsjinst, notearje wa’t it partikuliere adres besit, hokker sône it record hâldt en hokker resolvers derfoar antwurdzje moatte.
Dy koarte list foarkomt de meast foarkommende ferkearde diagnoaze op dit mêd: in wurkjende filiaaltunnel op ‘e nij starte om in record te reparearjen dat hielendal derbinnen libbet. De tunnel is it ferfier foar de tsjinstnamme; hy is net de autoriteit derfoar.
As der in feroaring foarsteld wurdt, freegje hokker fan de twa records it rekket. Kin nimmen antwurdzje, dan is de feroaring net klear om te plannen.
It einpunt moat oplost wurde foardat der hokker tunnel dan ek bestiet
Stel dat de ynternetferbining fan ‘e filiale in nij iepenbier adres krijt. De einpunt-bypwurker publisearret it nije adres, en de ôfstân-VPN-ymplemintaasje moat it feroare antwurd lêze kinne. Hokker resolver it antwurd ek jout, hy moat sûnder de tunnel berikber wêze, oars jaget de klient in namme nei dy’t er pas oplosse kin nei’t er ferbûn is mei datjinge dat er net fine kin.
Dy ôfhinklikens by it opstarten is it wurdich om dúdlik te sizzen, want hy ûntstiet maklik by ûngelok as alle ynterne resolvers efter de VPN sitte. Hâld in paad foar de tunnel foar it sykjen fan it einpunt, en befêstigje it werferbinen fan ‘e klient ynstee fan oan te nimmen dat in nij antwurd daliks oernaam wurdt.
Dynamyske DNS hat ek grinzen dy’t de record-bypwurking net oerstekke kin. It bywurkjen fan in record iepenet gjin firewallpoarte, makket gjin NAT-mapping en bewiist gjin pear-identiteit. In publisearre adres mei in sletten poarte jout in klient dy’t korrekt oplost en dochs nearne mei ferbine kin.
Ta beslút, in rinnende klient kin in cache-einpunt brûke bliuwe oant er wer ferbynt. Skiedje de publikaasje, de cache en it werferbyningsbelied yn jo notysjes, sadat in ferâldere pear net foar in stikken bypwurker oansjoen wurdt.
De tsjinstnamme beskriuwt wêr’t de applikaasje wennet
Stel no dat de tunnel sûn bliuwt mar de ynventarisaasjetsjinner ferhúzet fan 172.26.14.20 nei 172.26.14.35. It iepenbiere einpunt-record wurdt net rekke, wylst it partikuliere tsjinstrecord feroarje moat. It brûken fan in adres dat foar dy tsjinst reservearre is, of in statyske tawizing, makket dit seldsumer; in autorisearre bywurkingspaad behannelet de kearen dat it de bedoeling is.
Hjir wurde twa bywurkingsmeganismen trochelkoar helle. RFC 2136 definiearret in protokol om DNS-records yn in sône ta te foegjen en te wiskjen, wylst in kommersjele oanbieder fan dynamyske DNS in folslein oare HTTP-API foar in oar doel oanbiede kin. It brûken fan ien betsjut net dat de oare yn jo omjouwing bestiet. Kontrolearje hokker meganisme jo sône eins akseptearret foardat jo der in bypwurker tsjin skriuwe.
In korrekt partikulier antwurd is mar de earste betingst. Foar in ôfstân-opropper om it te brûken, hat de klient in resolver nedich dy’t de partikuliere sône draacht, in belied dat fragen nei dy resolver tastiet, en trochstjoering foar it adres dat weromkomt. In namme dy’t oplost nei in adres dat de klient net berikke kin, produsearret in time-out dy’t op in tsjinnerflater liket.
Test de twa paden apart
Kontrolearje it einpunt fan bûten de tunnel en de tsjinst fan binnen, en hâld de resultaten as twa ûnôfhinklike feiten:
$ 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
As de earste fraach mislearret, is it probleem de iepenbiere publikaasje of it oplossingspaad foar de tunnel, en gjin inkelde ynterne feroaring sil helpe. As de twadde in adres weromjout mar de tredde gjin rûte troch de tunnel sjen lit, is de DNS-laach yn oarder en it trochstjoeringsbelied net.
Rin it pear nei elke adresferoaring en notearje hokker record ferhuze is. In oerdracht dy’t allinnich seit «DNS is bywurke» lit de folgjende yngenieur riede hokker fan de twa libbenssyklussen eins rûn hat.