Migra tekokomputilo: stabila nomo aŭ fiksa oficeja adreso?

Vi malfermas la administran konzolon de hejme, serĉas la tekokomputilon laŭ nomo kaj ricevas adreson, kiu ĉesis validi kiam ĝi forlasis la oficejon. La instinkto estas porti la oficejan adreson sur la VPN-adaptilon, por ke ĉio daŭre funkciu. Tiu riparo kutime rompas ion alian, ĉar trovi aparaton, permesi ĝian trafikon kaj teni seancon viva estas tri malsamaj problemoj. Apartigu ilin antaŭ ol elekti adresan dezajnon.

Apartigu la tri postulojn

Skribu, kiu el la tri vere malsukcesas. Persono aŭ ilo ne povas trovi la servon; servilo rifuzas petojn ĉar la fonta adreso ne estas en listo; aŭ aplikaĵo falas kiam la interfaco ŝanĝiĝas. En kalkultabelo ili aspektas same kaj bezonas malsamajn riparojn.

Plej multaj migraj plendoj falas en la unuan korbon kaj estas riparataj en DNS. Nomigi stabilan identecon estas malmultekosta kaj kovras la unuan kazon. Konservi la adreson estas multekosta kaj helpas la duan nur se la politiko tamen estos reskribita.

Igu la nomon la stabila afero

Donu al la tekokomputilo nomon, kiu solviĝas al ajna adreso atingebla de la vokanto. En ĉi tiu ekzemplo la oficeja adreso estas 192.168.50.42, la fora alira naĝejo disdonas 10.90.0.42, kaj laptop17.corp.example sekvas la aliĝon. Nenio postulas, ke la lasta okto koincidu, kaj dezajni ĉirkaŭ tiu koincido kreas laboron sen profito. La rikordo devus montri al la adreso, kiun la vokanto vere povas uzi, ne al ĉiu interfaco, kiun la tekokomputilo iam havis.

dig +short laptop17.corp.example

Solviloj kaŝmemorigas respondojn, do la ŝanĝo ne estas tuja por ĉiuj. Mallongaj TTL-oj helpas, kaj la rekonekta logiko de la aplikaĵo helpas pli.

Kiam fonta permeslisto estas la reala limo

Fonta permeslisto vidas la adreson, kiun la protektita servo ricevas, post ajna traduko. Tio ofte estas pordega aŭ NAT-adreso anstataŭ la propra de la tekokomputilo, kaj tial redakti DNS-rikordojn neniam riparas rifuzitan peton. Ĝisdatigu la politikon por la adreso, kiu vere alvenas, aŭ anstataŭigu la liston per aŭtentikigita identeco.

Kaptu unu akceptitan peton en la servilo kaj legu la fontan kampon, poste ripetu de la fora vojo. Se la du adresoj diferencas, la politiko bezonas du rikordojn aŭ alian meĥanismon. Notu ambaŭ adresojn kun la politika rikordo, por ke la sekva persono vidu, kial estas du. Reuzi adreson, kiu jam estas aktiva sur la sama ligilo estas aparta konflikta problemo kun propraj reguloj por detekto.

Kion kontinueco vere postulas

Kontinueco de konekto estas la plej malfacila postulo kaj la plej ofte misinterpretita. TCP-konekto estas identigita per ambaŭ adresoj kaj ambaŭ pordoj, do nova loka adreso estas alia konekto, kion ajn diras DNS. Aplikaĵoj, kiuj gravas, devas rekonekti, kio signifas seanco-tavolon aŭ klienton, kiu reprovas, ne retan artifikon. Observu seancon dum la moviĝo kaj la interrompo estas tuja, ne laŭpaŝa.

ss -tnp state established '( dport = :443 )'

Klonado de MAC-adreso ankaŭ ne solvas tion. DHCP-lua identeco povas uzi eksplicitan klientan identigilon, kaj du interfacoj kun unu identeco ankoraŭ bezonas kunordigitajn vojojn. Traktu moveblecon kiel aplikaĵan kaj asignan dezajnon, kaj tenu la aparatan identecon stabila dum ĝia adreso sekvas la reton.