Vándorló laptop: stabil név vagy fix irodai cím?

Otthonról megnyitja a felügyeleti konzolt, név szerint megkeresi a laptopot, és olyan címet kap, amely már nem volt érvényes, amikor elhagyta az irodát. Az ösztön az, hogy átvigye az irodai címet a VPN-adapterre, hogy minden tovább működjön. Ez a javítás általában valami mást tör el, mert az eszköz megtalálása, forgalmának engedélyezése és a munkamenet életben tartása három különböző probléma. Válassza szét őket, mielőtt címtérvet választ.

Válassza szét a három követelményt

Írja le, melyik a három közül hibázik valójában. Egy személy vagy eszköz nem találja a szolgáltatást; egy kiszolgáló elutasítja a kéréseket, mert a forráscím nincs listán; vagy egy alkalmazás elszáll, amikor az interfész változik. Egy táblázatban egyformának tűnnek, és különböző javításokat igényelnek.

A legtöbb vándorlási panasz az első kosárba kerül, és a DNS-ben oldódik meg. Egy stabil identitás elnevezése olcsó, és lefedi az első esetet. A cím megőrzése drága, és csak akkor segít a másodikon, ha a szabályzatot amúgy is újraírják.

Tegye a nevet a stabil dologgá

Adjon a laptopnak olyan nevet, amely a hívó által elérhető bármely címre feloldódik. Ebben a példában az irodai cím 192.168.50.42, a távoli hozzáférési készlet 10.90.0.42 címet oszt, és a laptop17.corp.example követi a csatlakozást. Semmi sem írja elő, hogy az utolsó oktett egyezzen, és az egyezés körüli tervezés haszon nélküli munkát teremt. A rekordnak arra a címre kell mutatnia, amelyet a hívó valóban használhat, nem pedig minden interfészre, amellyel a laptop valaha rendelkezett.

dig +short laptop17.corp.example

A feloldók gyorsítótárazzák a válaszokat, ezért a változás nem azonnali mindenkinek. A rövid TTL-ek segítenek, az alkalmazás újracsatlakozási logikája pedig többet segít.

Amikor a forrásengedélyezési lista a valódi korlát

A forrásengedélyezési lista azt a címet látja, amelyet a védett szolgáltatás kap, bármilyen fordítás után. Ez gyakran átjáró- vagy NAT-cím, nem a laptop sajátja, ezért a DNS-rekordok szerkesztése soha nem javítja a visszautasított kérést. Frissítse a szabályzatot arra a címre, amely valóban megérkezik, vagy cserélje le a listát hitelesített identitásra.

Kapjon el egy elfogadott kérést a kiszolgálón, és olvassa ki a forrásmezőt, majd ismételje meg a távoli útvonalról. Ha a két cím eltér, a szabályzatnak két bejegyzésre vagy más mechanizmusra van szüksége. Jegyezze fel mindkét címet a szabályzat-bejegyzéssel együtt, hogy a következő személy lássa, miért van kettő. Egy már aktív cím újrafelhasználása ugyanazon a kapcsolaton külön ütközési probléma, saját felismerési szabályokkal.

Mit igényel valójában a folytonosság

A kapcsolat folytonossága a legnehezebb követelmény, és ezt értik félre a legtöbbször. A TCP-kapcsolatot mindkét cím és mindkét port azonosítja, ezért egy új helyi cím másik kapcsolat, bármit mond a DNS. A fontos alkalmazásoknak újra kell csatlakozniuk, ami munkamenet-réteget vagy újrapróbálkozó klienst jelent, nem hálózati trükköt. Figyeljen meg egy munkamenetet a mozgatás alatt, és a megszakadás azonnali, nem fokozatos.

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

A MAC-cím klónozása sem oldja meg ezt. A DHCP-bérlet identitása használhat kifejezett ügyfélazonosítót, és két interfész, amely egy identitást oszt meg, továbbra is összehangolt útvonalakat igényel. Kezelje a mobilitást alkalmazás- és kiosztástervezésként, és tartsa stabilan az eszköz identitását, miközben címe követi a hálózatot.