Omreisende laptop: stabilt navn eller fast kontoradresse?

Du åpner administrasjonskonsollen hjemmefra, søker etter laptopen på navn og får en adresse som ikke lenger var gyldig da den forlot kontoret. Instinktet er å flytte kontoradressen over på VPN-adapteren, slik at alt fortsetter å fungere. Den rettelsen ødelegger vanligvis noe annet, fordi å finne en enhet, tillate trafikken dens og holde en økt i live er tre forskjellige 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 er på en liste; eller en applikasjon faller når grensesnittet endres. I et regneark ser de like ut og krever forskjellige 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 på nytt.

Gjør navnet til det stabile

Gi laptopen et navn som løser til hvilken som helst adresse som er tilgjengelig for den som ringer. I dette eksempelet er kontoradressen 192.168.50.42, fjernadgangsbassenget 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 ringer 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 virkelige 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 den 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 egne deteksjonsregler.

Hva kontinuitet egentlig krever

Tilkoblingskontinuitet er det vanskeligste kravet og det som oftest leses feil. En TCP-tilkobling identifiseres av begge adressene og begge portene, så en ny lokal adresse er en annen tilkobling, 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.