Патнички лаптоп: стабилно име или фиксна адреса на канцеларија?

Ја отворате административната конзола од дома, го барате лаптопот по име и добивате адреса што престана да биде важечка кога тој ја напушти канцеларијата. Инстинктот е да се пренесе адресата на канцеларијата на VPN адаптерот за сѐ да продолжи да работи. Но таа поправка обично крши нешто друго, бидејќи пронаоѓањето уред, дозволувањето на неговиот сообраќај и одржувањето сесија жива се три различни проблеми. Одделете ги пред да изберете дизајн на адреси.

Одделете ги трите барања

Запишете кој од трите всушност не успева. Личност или алатка не може да ја најде услугата; серверот одбива барања затоа што изворната адреса не е на список; или апликацијата паѓа кога интерфејсот се менува. На табела изгледаат исто и бараат различни поправки.

Повеќето поплаки за движење паѓаат во првата кошница и се поправаат во DNS. Именувањето стабилен идентитет е ефтино и го покрива првиот случај. Зачувувањето на адресата е скапо и му помага на вториот само ако политиката и онака ќе се препише.

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

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

dig +short laptop17.corp.example

Решавачите кешираат одговори, па промената не е моментална за сите. Кратките TTL помагаат, а логиката за повторно поврзување на апликацијата помага повеќе.

Кога списокот на дозволени извори е вистинското ограничување

Списокот на дозволени извори ја гледа адресата што ја прима заштитената услуга, по секое преведување. Тоа често е адреса на порта или NAT, а не на самиот лаптоп, затоа уредувањето на DNS записите никогаш не поправа одбиено барање. Ажурирајте ја политиката за адресата што навистина пристигнува, или заменете го списокот со автентификуван идентитет.

Фатете едно прифатено барање на серверот и прочитајте го полето за извор, потоа повторете од далечинската патека. Ако двете адреси се разликуваат, на политиката ѝ требаат два записи или друг механизам. Запишете ги двете адреси со записот на политиката за следниот човек да види зошто се две. Повторно користење адреса што е веќе активна на истата врска е одделен проблем со конфликт со сопствени правила за откривање.

Што всушност бара континуитетот

Континуитетот на врската е најтешкото барање и она што најчесто се чита погрешно. TCP врската се идентификува со двете адреси и двата порта, па новата локална адреса е друга врска, што и да каже DNS. Важните апликации мора да се поврзат повторно, што значи сесиски слој или клиент што повторно обидува, а не мрежен трик. Набљудувајте сесија за време на преместувањето и прекинот е моментален, не постепен.

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

Клонирањето MAC адреса исто така не го решава ова. Идентитетот на DHCP закупот може да користи експлицитен идентификатор на клиент, а два интерфејси што делат еден идентитет сѐ уште бараат координирани рути. Третирајте ја мобилноста како дизајн на апликација и доделување, и држете го идентитетот на уредот стабилен додека неговата адреса го следи мрежата.