Omreisande laptop: stabilt namn eller fast kontoradresse?

Du opnar administrasjonskonsollen heimanfrå, søkjer opp laptopen på namn og får ei adresse som slutta å vere gyldig då han forlét kontoret. Instinktet er å flytte kontoradressa over på VPN-adapteren slik at alt held fram med å verke. Den rettinga øydelegg vanlegvis noko anna, fordi det å finne ei eining, tillate trafikken hennar og halde ei økt i live er tre ulike problem. Skil dei før du vel ein adressedesign.

Skil dei tre krava

Skriv ned kva av dei tre som faktisk sviktar. Ein person eller eit verktøy finn ikkje tenesta; ein server avviser førespurnader fordi kjeldeadressa ikkje står på ei liste; eller eit program fell når grensesnittet endrar seg. I eit rekneark ser dei like ut og krev ulike rettingar.

Dei fleste roamingklager hamnar i den første kategorien og blir retta i DNS. Å namngje ein stabil identitet er billeg og dekkjer det første tilfellet. Å ta vare på adressa er dyrt og hjelper berre det andre om policyen uansett blir skriven om.

Gjer namnet til det stabile

Gje laptopen eit namn som løyser til kva som helst adresse som er nåbar for den som ringjer. I dette dømet er kontoradressa 192.168.50.42, fjerntilgangsbassenget deler ut 10.90.0.42, og laptop17.corp.example følgjer tilkoplinga. Ingenting krev at den siste oktetten stemmer, og å designe rundt den overeinskomsten skaper arbeid utan nytte. Oppføringa bør peike på adressa den som ringjer faktisk kan bruke, ikkje på kvart grensesnitt laptopen nokon gong har hatt.

dig +short laptop17.corp.example

Resolvarar cachar svar, så endringa er ikkje umiddelbar for alle. Korte TTL-ar hjelper, og attilkoplingslogikken til programmet hjelper meir.

Når ei kjelde-tillatelsesliste er den reelle avgrensinga

Ei kjelde-tillatelsesliste ser adressa den verna tenesta mottek, etter kvar som helst omsetjing. Det er ofte ei gateway- eller NAT-adresse og ikkje laptopa si eiga, og difor reparerer redigering av DNS-oppføringar aldri ein avvist førespurnad. Oppdater policyen for adressa som faktisk kjem inn, eller byt ut lista med ein autentisert identitet.

Fang éin godkjend førespurnad på serveren og les kjeldeteltet, og gjer det om att frå fjernstien. Viss dei to adressene er ulike, treng policyen to oppføringar eller ein annan mekanisme. Noter båe adressene saman med policyoppføringa slik at neste person ser kvifor det er to. Å bruke om att ei adresse som allereie er aktiv på same lenkja er eit separat konfliktproblem med sine eigne deteksjonsreglar.

Kva samanheng eigentleg krev

Samheng i sambandet er det vanskelegaste kravet og det som oftast blir lese feil. Eit TCP-samband blir identifisert av båe adressene og båe portane, så ei ny lokal adresse er eit anna samband, same kva DNS seier. Program som tel, må kople til på nytt, noko som tyder eit øktlag eller ein klient som prøver om att, ikkje eit nettverkstriks. Overvak ei økt under flyttinga, og brotet er umiddelbart, ikkje gradvis.

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

Å klone ei MAC-adresse løyser heller ikkje dette. DHCP-leigeidentitet kan bruke ein eksplisitt klientidentifikator, og to grensesnitt som deler éin identitet treng framleis koordinerte ruter. Handsame mobilitet som ein program- og tildelingsdesign, og hald identiteten til eininga stabil medan adressa hennar følgjer nettverket.