Enw penbwynt VPN yn erbyn enw gwasanaeth preifat: dau berchennog

Gall dau enw ddisgrifio’r un gangen ac ateb cwestiynau hollol wahanol. Mae vpn.branch.example yn dweud wrth bartner o bell ble i ddod o hyd i’r penbwynt VPN, ac mae’n rhaid ei ddatrys cyn bod unrhyw dwnnel yn bodoli. Mae inventory.branch.example yn dweud wrth ddefnyddiwr awdurdodedig ble mae cymhwysiad preifat yn byw, ac mae ond yn bwysig unwaith y bydd y twnnel i fyny. Nid yw cynnal un ohonynt yn gwneud dim i’r llall.

Enwch y ddau gofnod cyn datbygio’r naill na’r llall

Ysgrifennwch y ddau gyda’u perchnogion. Ar gyfer y penbwynt, cofnodwch pwy sy’n diweddaru’r cyfeiriad cyhoeddus a sut mae’r cleient VPN yn adfywio’i ateb. Ar gyfer y gwasanaeth, cofnodwch pwy sy’n berchen ar y cyfeiriad preifat, pa barth sy’n dal y cofnod, a pha ddatryswyr a ddylai ateb drosto.

Mae’r rhestr fer hon yn atal y camddiagnosis mwyaf cyffredin yn y maes hwn: ailgychwyn twnnel cangen sy’n gweithio er mwyn trwsio cofnod sy’n byw’n gyfan gwbl y tu mewn iddo. Y twnnel yw’r cludiant ar gyfer enw’r gwasanaeth; nid ef yw’r awdurdod drosto.

Pan gynigir newid, gofynnwch pa un o’r ddau gofnod y mae’n ei gyffwrdd. Os na all neb ateb, nid yw’r newid yn barod i’w drefnu.

Rhaid i’r penbwynt ddatrys cyn bod unrhyw dwnnel yn bodoli

Tybiwch fod cysylltiad rhyngrwyd y gangen yn cael cyfeiriad cyhoeddus newydd. Mae’r diweddarwr penbwynt yn cyhoeddi’r cyfeiriad newydd, ac mae’n rhaid i weithrediad VPN o bell allu darllen yr ateb a newidiwyd. Rhaid i ba ddatryswr bynnag sy’n darparu’r ateb hwnnw fod yn gyrhaeddadwy heb y twnnel, neu mae’r cleient yn erlid enw na all ei ddatrys ond ar ôl cysylltu â’r peth na all ddod o hyd iddo.

Mae’r ddibyniaeth gychwynnol hon yn werth ei datgan yn blwmp, oherwydd mae’n hawdd ei chreu ar ddamwain pan fydd pob datryswr mewnol y tu ôl i’r VPN. Cadwch lwybr cyn y twnnel ar gyfer chwilio’r penbwynt, a chadarnhewch ymddygiad ailgysylltu’r cleient yn hytrach na thybio bod ateb newydd yn cael ei godi ar unwaith.

Mae gan DNS deinamig hefyd derfynau na all y diweddariad cofnod eu croesi. Nid yw diweddaru cofnod yn agor unrhyw borth tân, nac yn creu mapio NAT, nac yn profi hunaniaeth partner. Mae cyfeiriad cyhoeddedig â phorth caeedig yn rhoi cleient sy’n datrys yn gywir ac yn dal i fethu cysylltu â dim.

Yn olaf, gall cleient sy’n rhedeg barhau i ddefnyddio penbwynt wedi’i gacheio nes iddo ailgysylltu. Gwahanwch y cyhoeddiad, y cache a’r polisi ailgysylltu yn eich nodiadau, fel na chaiff partner darfodedig ei gamgymryd am ddiweddarwr wedi torri.

Mae enw’r gwasanaeth yn disgrifio ble mae’r cymhwysiad yn byw

Nawr tybiwch fod y twnnel yn aros yn iach ond bod y gweinydd rhestr yn symud o 172.26.14.20 i 172.26.14.35. Nid yw cofnod cyhoeddus y penbwynt yn cael ei effeithio, tra bod yn rhaid i gofnod preifat y gwasanaeth newid. Mae defnyddio cyfeiriad a gadwyd ar gyfer y gwasanaeth hwnnw, neu aseiniad statig, yn gwneud hyn yn brinnach; mae llwybr diweddaru awdurdodedig yn ymdrin â’r adegau pan fwriedir hynny.

Mae dau fecanwaith diweddaru’n cael eu cymysgu yma. Mae RFC 2136 yn diffinio protocol ar gyfer ychwanegu a dileu cofnodion DNS mewn parth, tra gall darparwr DNS deinamig masnachol gynnig API HTTP hollol wahanol at ddiben gwahanol. Nid yw defnyddio’r naill yn awgrymu bod y llall yn bodoli yn eich amgylchedd. Gwiriwch ba fecanwaith y mae eich parth yn ei dderbyn mewn gwirionedd cyn ysgrifennu diweddarwr yn ei erbyn.

Nid yw ateb preifat cywir ond y mater cyntaf. Er mwyn i alwyr o bell ei ddefnyddio, mae angen datryswr sy’n cario’r parth preifat, polisi sy’n caniatáu ymholiadau i’r datryswr hwnnw, a blaendrosiad ar gyfer y cyfeiriad sy’n dychwelyd. Mae enw sy’n datrys i gyfeiriad na all y cleient ei gyrraedd yn cynhyrchu terfyn amser sy’n edrych fel nam gweinydd.

Profwch y ddau lwybr ar wahân

Gwiriwch y penbwynt o du allan i’r twnnel a’r gwasanaeth o’i du mewn, a chadwch y canlyniadau fel dau ffaith annibynnol:

$ 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

Os bydd yr ymholiad cyntaf yn methu, y broblem yw’r cyhoeddiad cyhoeddus neu’r llwybr datrys cyn y twnnel, ac ni fydd unrhyw newid mewnol yn helpu. Os bydd yr ail yn dychwelyd cyfeiriad ond nad yw’r trydydd yn dangos unrhyw lwybr drwy’r twnnel, mae haen DNS yn iawn a’r polisi blaendrosi ddim.

Rhedwch y pâr ar ôl pob newid cyfeiriad, a nodwch ba gofnod a symudodd. Mae trosglwyddiad sy’n dweud yn unig «diweddarwyd DNS» yn gadael y peiriannydd nesaf i ddyfalu pa un o’r ddau gylch bywyd a redodd mewn gwirionedd.