Přenosný notebook: stabilní jméno, nebo pevná adresa kanceláře?

Otevřete správcovskou konzoli z domova, vyhledáte notebook podle jména a dostanete adresu, která přestala platit, jakmile opustil kancelář. Instinkt je přenést adresu kanceláře na adaptér VPN, aby všechno fungovalo dál. Taková oprava obvykle rozbije něco jiného, protože najít zařízení, povolit jeho provoz a udržet relaci naživu jsou tři různé problémy. Oddělte je, než zvolíte návrh adres.

Oddělte tři požadavky

Zapište, který ze tří skutečně selhává. Člověk nebo nástroj nenajde službu; server odmítá požadavky, protože zdrojová adresa není v seznamu; nebo aplikace spadne, když se změní rozhraní. V tabulce vypadají stejně a vyžadují různé opravy.

Většina stížností na roaming skončí v první kategorii a opraví se v DNS. Pojmenování stabilní identity je levné a pokrývá první případ. Zachování adresy je drahé a pomáhá druhému jen tehdy, když se politika stejně přepíše.

Udělejte jménem tu stabilní věc

Dejte notebooku jméno, které se přeloží na jakoukoli adresu dostupnou volajícímu. V tomto příkladu je adresa kanceláře 192.168.50.42, fond vzdáleného přístupu přiděluje 10.90.0.42 a laptop17.corp.example sleduje připojení. Nic nevyžaduje shodu posledního oktetu a navrhovat kolem této shody vytváří práci bez užitku. Záznam má ukazovat na adresu, kterou volající skutečně může použít, ne na každé rozhraní, které notebook kdy měl.

dig +short laptop17.corp.example

Resolverové kešují odpovědi, takže změna není pro všechny okamžitá. Krátké TTL pomáhají a logika opětovného připojení v aplikaci pomáhá víc.

Když je skutečným omezením seznam povolených zdrojů

Seznam povolených zdrojů vidí adresu, kterou chráněná služba dostane, po každém překladu. Často je to adresa brány nebo NAT, ne notebooku samotného, a proto úprava záznamů DNS nikdy neopraví odmítnutý požadavek. Aktualizujte politiku pro adresu, která skutečně dorazí, nebo nahraďte seznam ověřenou identitou.

Zachyťte na serveru jeden přijatý požadavek a přečtěte pole zdroje, pak to zopakujte ze vzdálené cesty. Pokud se obě adresy liší, politika potřebuje dva záznamy nebo jiný mechanismus. Zapište obě adresy k záznamu politiky, aby další člověk viděl, proč jsou dvě. Opětovné použití adresy, která je už na stejném spoji aktivní je samostatný problém konfliktu s vlastními pravidly detekce.

Co skutečně vyžaduje nepřerušené spojení

Nepřerušené spojení je nejtěžší požadavek a ten nejčastěji špatně chápaný. Spojení TCP je identifikováno oběma adresami a oběma porty, takže nová místní adresa je jiné spojení, ať DNS říká cokoli. Aplikace, na kterých záleží, se musí znovu připojit, což znamená relační vrstvu nebo klienta, který to zkouší znovu, ne síťový trik. Sledujte relaci během přesunu a výpadek je okamžitý, ne postupný.

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

Klonování MAC adresy to také neřeší. Identita DHCP pronájmu může použít explicitní identifikátor klienta a dvě rozhraní sdílející jednu identitu stále potřebují koordinované trasy. Berte mobilitu jako návrh aplikace a přidělování a držte identitu zařízení stabilní, zatímco jeho adresa sleduje síť.