Omreisende laptop: stabilt navn eller fast kontoradresse?

Du åpner administrasjonskonsollen hjemmefra, søker opp laptopen på navn og får en adresse som sluttet å være gyldig da den forlot kontoret. Instinktet er å flytte kontoradressen over på VPN-adapteren slik at alt fortsetter å virke. Den rettelsen ødelegger vanligvis noe annet, fordi det å finne en enhet, tillate trafikken dens og holde en økt i live er tre ulike problemer. Skill dem før du velger en adressedesign.

Skill de tre kravene

Skriv ned hvilket av de tre som faktisk svikter. En person eller et verktøy finner ikke tjenesten; en server avviser forespørsler fordi kildeadressen ikke står på en liste; eller en applikasjon faller når grensesnittet endres. I et regneark ser de like ut og krever ulike rettelser.

De fleste roamingklager havner i den første kategorien og rettes i DNS. Å navngi en stabil identitet er billig og dekker det første tilfellet. Å bevare adressen er dyrt og hjelper bare det andre hvis policyen uansett skrives om.

Gjør navnet til det stabile

Gi laptopen et navn som løses til hvilken som helst adresse som er nåbar for den som kaller. I dette eksemplet er kontoradressen 192.168.50.42, fjernadgangspoolen deler ut 10.90.0.42, og laptop17.corp.example følger tilkoblingen. Ingenting krever at den siste oktetten stemmer, og å designe rundt den overensstemmelsen skaper arbeid uten nytte. Oppføringen bør peke på adressen den som kaller faktisk kan bruke, ikke på hvert grensesnitt laptopen noen gang har hatt.

dig +short laptop17.corp.example

Resolvere cacher svar, så endringen er ikke umiddelbar for alle. Korte TTL-er hjelper, og applikasjonens gjenoppkoblingslogikk hjelper mer.

Når en kildetillatelsesliste er den reelle begrensningen

En kildetillatelsesliste ser adressen den beskyttede tjenesten mottar, etter enhver oversettelse. Det er ofte en gateway- eller NAT-adresse og ikke laptopens egen, og derfor reparerer redigering av DNS-oppføringer aldri en avvist forespørsel. Oppdater policyen for adressen som faktisk ankommer, eller erstatt listen med en autentisert identitet.

Fang én godkjent forespørsel på serveren og les kildefeltet, og gjenta deretter fra fjernstien. Hvis de to adressene er forskjellige, trenger policyen to oppføringer eller en annen mekanisme. Noter begge adressene sammen med policyoppføringen slik at neste person ser hvorfor det er to. Å gjenbruke en adresse som allerede er aktiv på samme lenke er et separat konfliktproblem med sine egne deteksjonsregler.

Hva kontinuitet egentlig krever

Forbindelseskontinuitet er det vanskeligste kravet og det som oftest leses feil. En TCP-forbindelse identifiseres av begge adressene og begge portene, så en ny lokal adresse er en annen forbindelse, uansett hva DNS sier. Applikasjoner som betyr noe, må koble til på nytt, noe som betyr et øktlag eller en klient som prøver igjen, ikke et nettverkstriks. Overvåk en økt under flyttingen, og avbruddet er umiddelbart, ikke gradvis.

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

Å klone en MAC-adresse løser heller ikke dette. DHCP-leieidentitet kan bruke en eksplisitt klientidentifikator, og to grensesnitt som deler én identitet trenger fortsatt koordinerte ruter. Behandle mobilitet som en applikasjons- og tildelingsdesign, og hold enhetens identitet stabil mens adressen følger nettverket.