Ombærende laptop: stabilt navn eller fast kontoradresse?
At finde en laptop, tillade dens trafik og holde en session i live er tre forskellige roamingproblemer. Afgør, hvilket du faktisk har.
Du åbner administrationskonsollen hjemmefra, søger efter laptop’en på navn og får en adresse, der holdt op med at være gyldig, da den forlod kontoret. Instinktet er at flytte kontoradressen over på VPN-adapteren, så alt fortsætter med at virke. Den rettelse ødelægger som regel noget andet, fordi det at finde en enhed, tillade dens trafik og holde en session i live er tre forskellige problemer. Adskil dem, før du vælger et adressedesign.
Adskil de tre krav
Skriv ned, hvilket af de tre der faktisk fejler. En person eller et værktøj kan ikke finde tjenesten; en server afviser anmodninger, fordi kildeadressen ikke står på en liste; eller en applikation falder, når grænsefladen skifter. På et regneark ser de ens ud og kræver forskellige rettelser.
De fleste roamingklager lander i den første kategori og bliver rettet i DNS. At navngive en stabil identitet er billigt og dækker det første tilfælde. Adressebevarelse er dyrt og hjælper kun det andet, hvis politikken alligevel skrives om.
Gør navnet til det stabile
Giv laptop’en et navn, der opløses til den adresse, som kalderen kan nå. I dette eksempel er kontoradressen 192.168.50.42, fjernadgangspuljen uddeler 10.90.0.42, og laptop17.corp.example følger tilslutningen. Intet kræver, at den sidste oktet matcher, og at designe omkring det match skaber arbejde uden gevinst. Posten skal pege på den adresse, kalderen faktisk kan bruge, ikke på hver grænseflade, laptop’en nogensinde har haft.
dig +short laptop17.corp.exampleResolverne cacher svar, så ændringen er ikke øjeblikkelig for alle. Korte TTL’er hjælper, og applikationens genopkoblingslogik hjælper mere.
Når en kilde-tilladelsesliste er den reelle begrænsning
En kilde-tilladelsesliste ser den adresse, den beskyttede tjeneste modtager, efter enhver oversættelse. Det er ofte en gateway- eller NAT-adresse i stedet for laptop’ens egen, og derfor reparerer redigering af DNS-poster aldrig en afvist anmodning. Opdater politikken for den adresse, der faktisk ankommer, eller erstat listen med en autentificeret identitet.
Fang en accepteret anmodning på serveren, og læs kildefeltet, og gentag derefter fra fjernstien. Hvis de to adresser er forskellige, har politikken brug for to poster eller en anden mekanisme. Notér begge adresser sammen med politikposten, så den næste person kan se, hvorfor der er to. At genbruge en adresse, der allerede er aktiv på samme forbindelse er et separat konfliktproblem med sine egne registreringsregler.
Hvad kontinuitet egentlig kræver
Forbindelseskontinuitet er det sværeste krav og det, der oftest læses forkert. En TCP-forbindelse identificeres ved begge adresser og begge porte, så en ny lokal adresse er en anden forbindelse, uanset hvad DNS siger. Applikationer, der betyder noget, skal genopkoble, hvilket betyder et sessionslag eller en klient, der prøver igen, ikke et netværkstrick. Overvåg en session under flytningen, og afbrydelsen er øjeblikkelig, ikke gradvis.
ss -tnp state established '( dport = :443 )'At klone en MAC-adresse løser heller ikke dette. DHCP-lejeidentitet kan bruge en eksplicit klientidentifikator, og to grænseflader, der deler én identitet, har stadig brug for koordinerede ruter. Behandl mobilitet som et applikations- og tildelingsdesign, og hold enhedens identitet stabil, mens dens adresse følger netværket.