Kringresande laptop: stabilt namn eller fast kontorsadress?

Du öppnar administrationskonsolen hemifrån, söker upp laptopen på namn och får en adress som slutade vara giltig när den lämnade kontoret. Instinkten är att flytta kontorsadressen till VPN-adaptern så att allt fortsätter att fungera. Den korrigeringen brukar förstöra något annat, eftersom att hitta en enhet, tillåta dess trafik och hålla en session vid liv är tre olika problem. Separera dem innan du väljer en adressdesign.

Separera de tre kraven

Skriv ned vilket av de tre som faktiskt misslyckas. En person eller ett verktyg hittar inte tjänsten; en server nekar förfrågningar eftersom källadressen inte finns på en lista; eller ett program kraschar när gränssnittet ändras. I ett kalkylblad ser de likadana ut och kräver olika åtgärder.

De flesta roamingklagomål hamnar i den första kategorin och åtgärdas i DNS. Att namnge en stabil identitet är billigt och täcker det första fallet. Att bevara adressen är dyrt och hjälper bara det andra om policyn ändå skrivs om.

Gör namnet till det stabila

Ge laptopen ett namn som löses till vilken adress som helst som är nåbar för den som anropar. I det här exemplet är kontorsadressen 192.168.50.42, fjärråtkomstpoolen delar ut 10.90.0.42, och laptop17.corp.example följer anslutningen. Inget kräver att det sista oktetten stämmer, och att designa kring den överensstämmelsen skapar arbete utan nytta. Posten bör peka på adressen som den som anropar faktiskt kan använda, inte på varje gränssnitt som laptopen någonsin har haft.

dig +short laptop17.corp.example

Resolverare cachelagrar svar, så ändringen är inte omedelbar för alla. Korta TTL:er hjälper, och programmets återanslutningslogik hjälper mer.

När en källtillåtelselista är den verkliga begränsningen

En källtillåtelselista ser adressen som den skyddade tjänsten tar emot, efter varje översättning. Det är ofta en gateway- eller NAT-adress och inte laptopens egen, och därför reparerar redigering av DNS-poster aldrig en avvisad förfrågan. Uppdatera policyn för adressen som faktiskt anländer, eller ersätt listan med en autentiserad identitet.

Fånga en accepterad förfrågan på servern och läs källfältet, och upprepa sedan från fjärrvägen. Om de två adresserna skiljer sig behöver policyn två poster eller en annan mekanism. Anteckna båda adresserna tillsammans med policyposten så att nästa person ser varför det finns två. Att återanvända en adress som redan är aktiv på samma länk är ett separat konfliktproblem med egna identifieringsregler.

Vad kontinuitet egentligen kräver

Anslutningens kontinuitet är det svåraste kravet och det som oftast misstolkas. En TCP-anslutning identifieras av båda adresserna och båda portarna, så en ny lokal adress är en annan anslutning, vad DNS än säger. Program som spelar roll måste återansluta, vilket betyder ett sessionslager eller en klient som försöker igen, inte ett nätverkstrick. Observera en session under flytten och avbrottet är omedelbart, inte gradvis.

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

Att klona en MAC-adress löser inte heller detta. DHCP-leasingens identitet kan använda en explicit klientidentifierare, och två gränssnitt som delar en identitet behöver fortfarande koordinerade rutter. Behandla mobilitet som en program- och tilldelningsdesign, och håll enhetens identitet stabil medan dess adress följer nätverket.