Роуминг лаптоп: стабилно име или фиксиран адрес на офиса?

Отваряте конзолата за управление от вкъщи, търсите лаптопа по име и получавате адрес, който е престанал да е валиден, когато той е напуснал офиса. Инстинктът е да пренесете офисния адрес върху VPN адаптера, за да продължи всичко да работи. Тази поправка обикновено чупи нещо друго, защото намирането на устройство, разрешаването на трафика му и поддържането на сесия жива са три различни проблема. Разделете ги, преди да изберете дизайн на адресите.

Разделете трите изисквания

Запишете кое от трите всъщност се проваля. Човек или инструмент не може да намери услугата; сървър отказва заявки, защото адресът на източника не е в списък; или приложение прекъсва, когато интерфейсът се промени. В електронна таблица изглеждат еднакво и изискват различни поправки.

Повечето оплаквания от роуминг попадат в първата кошница и се оправят в DNS. Назоваването на стабилна идентичност е евтино и покрива първия случай. Запазването на адреса е скъпо и помага на втория само ако политиката все пак бъде пренаписана.

Направете името стабилното нещо

Дайте на лаптопа име, което се разрешава до какъвто и адрес да е достъпен за викащия. В този пример офисният адрес е 192.168.50.42, пулът за отдалечен достъп раздава 10.90.0.42, а laptop17.corp.example следва прикачването. Нищо не изисква последният октет да съвпада, а проектирането около това съвпадение създава работа без полза. Записът трябва да сочи към адреса, който викащият реално може да използва, а не към всеки интерфейс, който лаптопът някога е имал.

dig +short laptop17.corp.example

Resolver-ите кешират отговори, така че промяната не е мигновена за всички. Кратките TTL помагат, а логиката за повторно свързване в приложението помага повече.

Когато списъкът с разрешени източници е истинското ограничение

Списъкът с разрешени източници вижда адреса, който защитената услуга получава, след всяко преобразуване. Това често е адрес на шлюз или NAT, а не собственият адрес на лаптопа, затова редактирането на DNS записи никога не поправя отхвърлена заявка. Актуализирайте политиката за адреса, който реално пристига, или заменете списъка с удостоверена идентичност.

Уловете една приета заявка на сървъра и прочетете полето за източник, след което повторете от отдалечения път. Ако двата адреса се различават, политиката се нуждае от два записа или различен механизъм. Запишете двата адреса заедно със записа на политиката, за да види следващият човек защо има два. Повторното използване на адрес, който вече е активен на същата връзка е отделен проблем със конфликт със собствени правила за откриване.

Какво всъщност изисква непрекъснатостта

Непрекъснатостта на връзката е най-трудното изискване и това, което най-често се разбира погрешно. TCP връзката се идентифицира по двата адреса и двата порта, така че нов локален адрес е друга връзка, независимо какво казва DNS. Приложенията, които имат значение, трябва да се свържат отново, което означава сесиен слой или клиент, който повтаря, а не мрежов трик. Наблюдавайте сесия по време на преместването и прекъсването е моментално, не постепенно.

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

Клонирането на MAC адрес също не решава това. Идентичността на DHCP наема може да използва явен идентификатор на клиента, а два интерфейса, споделящи една идентичност, все още се нуждаят от координирани маршрути. Третирайте мобилността като дизайн на приложението и разпределението, и дръжте идентичността на устройството стабилна, докато адресът му следва мрежата.