Vaelteleva kannettava: vakaa nimi vai kiinteä toimisto-osoite?

Avaat hallintakonsolin kotoa, etsit kannettavan nimellä ja saat osoitteen, joka lakkasi olemasta kelvollinen, kun se lähti toimistosta. Vaisto on siirtää toimiston osoite VPN-sovittimelle, jotta kaikki jatkuu toimintana. Se korjaus rikkoo yleensä jotain muuta, sillä laitteen löytäminen, sen liikenteen salliminen ja istunnon pitäminen elossa ovat kolme eri ongelmaa. Erottele ne ennen osoitesuunnittelun valintaa.

Erottele kolme vaatimusta

Kirjoita ylös, mikä kolmesta oikeasti epäonnistuu. Henkilö tai työkalu ei löydä palvelua; palvelin hylkää pyynnöt, koska lähdeosoite ei ole listalla; tai sovellus putoaa, kun liitäntä vaihtuu. Taulukossa ne näyttävät samoilta ja vaativat erilaisia korjauksia.

Useimmat roaming-valitukset päätyvät ensimmäiseen koriin ja korjataan DNS:ssä. Vakaan identiteetin nimeäminen on halpaa ja kattaa ensimmäisen tapauksen. Osoitteen säilyttäminen on kallista ja auttaa toista vain, jos käytäntö kirjoitetaan joka tapauksessa uudelleen.

Tee nimestä vakaa asia

Anna kannettavalle nimi, joka ratkeaa mihin tahansa osoitteeseen, joka on kutsujan saavutettavissa. Tässä esimerkissä toimiston osoite on 192.168.50.42, etäkäyttöaltaasta jaetaan 10.90.0.42, ja laptop17.corp.example seuraa liitosta. Mikään ei vaadi viimeisen oktetun täsmäämistä, ja sen täsmäämisen ympärille suunnitteleminen luo työtä ilman hyötyä. Tietueen pitäisi osoittaa osoitteeseen, jota kutsuja voi oikeasti käyttää, ei jokaiseen liitäntään, joka kannettavalla on koskaan ollut.

dig +short laptop17.corp.example

Ratkaisijat välimuistittavat vastauksia, joten muutos ei ole kaikille välitön. Lyhyet TTL-arvot auttavat, ja sovelluksen uudelleenyhdistämislogiikka auttaa enemmän.

Kun lähdeallowlista on todellinen rajoite

Lähdeallowlista näkee osoitteen, jonka suojattu palvelu vastaanottaa, minkä tahansa käännöksen jälkeen. Se on usein yhdyskäytävän tai NAT:n osoite eikä kannettavan oma, minkä vuoksi DNS-tietueiden muokkaaminen ei koskaan korjaa hylättyä pyyntöä. Päivitä käytäntö osoitteelle, joka todella saapuu, tai korvaa lista todennetulla identiteetillä.

Nappaa palvelimella yksi hyväksytty pyyntö ja lue lähdekenttä, ja toista sitten etäpolulta. Jos kaksi osoitetta eroavat, käytäntö tarvitsee kaksi merkintää tai toisen mekanismin. Kirjaa molemmat osoitteet käytäntömerkinnän kanssa, jotta seuraava henkilö näkee, miksi niitä on kaksi. Jo samalla linkillä aktiivisen osoitteen uudelleenkäyttö on erillinen ristiriitaongelma omine tunnistussääntöineen.

Mitä jatkuvuus oikeasti vaatii

Yhteyden jatkuvuus on vaikein vaatimus ja useimmin väärin luettu. TCP-yhteys tunnistetaan molemmista osoitteista ja molemmista porteista, joten uusi paikallinen osoite on toinen yhteys, mitä DNS sanoo. Tärkeiden sovellusten on yhdistettävä uudelleen, mikä tarkoittaa istuntokerrosta tai uudelleen yrittävää asiakasta, ei verkkokikkaa. Seuraa istuntoa siirtymän aikana, ja katkeaminen on välitön, ei vähittäinen.

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

MAC-osoitteen kloonaaminenkaan ei ratkaise tätä. DHCP-vuokrauksen identiteetti voi käyttää eksplisiittistä asiakastunnistetta, ja kaksi liitäntää, jotka jakavat yhden identiteetin, tarvitsevat silti koordinoidut reitit. Kohtele liikkuvuutta sovellus- ja allokointisuunnitteluna ja pidä laitteen identiteetti vakaana, kun sen osoite seuraa verkkoa.