Централизујте приступ партнера VPN-у без спајања партнера

Предлог је разуман: пет партнерских тунела разбацаних по десетак лаптопова, пет комплета верзија клијента, пет скрипти за подршку и један инжењер који зна како се све то уклапа. Њихово пребацивање на контролисани ниво приступа решава раштрканост крајњих тачака. Истовремено ствара нови објекат у архитектури — заједничку услугу приступа којој је сада потребан сопствени модел овлашћења; а отказ који сви потцењују јесте централни уређај са укљученим свим тунелима који тихо постаје транзитна мрежа између организација које никада нису пристале да буду суседи. Тај ризик је дизајнерска одлука, а не нешто што хардвер ради сам. Рад испод је начин да задржим погодност без прихватања случајног нежељеног ефекта.

Почните од уговора који је сваки партнер већ потписао

Пре било какве конфигурације, потврдите да партнер уопште дозвољава заједнички пролаз или повезивање локације. Лични налог за удаљени приступ, захтев за стањем уређаја или интерактивни MFA ток можда нису преносиви на заједнички тунел без надзора, а груписање запослених иза једног копираног идентитета клијента је она врста пречице која траје док партнер не прегледа своје дневнике. За сваку дозвољену везу запишите опсеге одредишта, приватне DNS домене, овлашћене унутрашње изворе, власника аутентификације и шта треба да се догоди када тунел откаже. Замолите партнера да писмено потврди заједничку везу, укључујући опсеге извора које ће прихватити. Усмено одобрење обично промени значење у недељи када се замени њихов безбедносни тим.

Тај запис је резултат. Ако не можете да га напишете за једног партнера, тај партнер није спреман за централизацију.

Рутирајте по контексту, а не само по одредишту

Два партнера ће на крају користити исти приватни опсег, јер свака организација бира из истог простора RFC 1918. Једна обична табела рутирања не може да изабере правог партнера само на основу адресе одредишта, па опсези који се преклапају захтевају одвојене контексте рутирања или други договорени дизајн. Модел домена прослеђивања у RFC 4364 описује зашто је то раздвајање важно, а распоређивање не мора да покреће MPLS да би од своје платформе пролаза захтевало исто својство.

Поставите платформи директно питање: могу ли два партнера да деле исти префикс одредишта и ипак буду раздвојени по томе из контекста ког запосленог је сесија дошла? Ако је одговор не, то ограничење обликује дизајн више од било које листе функција добављача.

Где је одговор да, контекст рутирања постаје оно што документујете и тестирате, јер је невидљив у traceroute-у.

Одлучите шта запослени уноси, а шта партнер бележи

Део партнерског посла одговара апликацијском проксију или удаљеном радном простору отвореном у контексту тог партнера. Други посао захтева рутирани мрежни приступ из одобреног сегмента запослених, а оба дају различите изворне адресе и различите трагове ревизије на далекој страни. Заједничка преведена изворна адреса може да задовољи листу дозвола док истовремено скрива који је уређај шта урадио, зато сачувајте поуздану везу запосленог са сесијом и задржите аутентификацију апликације уместо да адресу пролаза третирате као идентитет — што је згодно све до тренутка када партнер пита ко је то урадио.

Затим прођите један стварни задатак са стране запосленог: на шта кликћу, шта се од њих тражи и шта би партнер видео ако би затражио запис у дневнику. Ако тај пролаз није поновљив, дизајн није завршен.

Изричито забраните транзит између партнера

Заједнички хардвер никада не треба да значи заједничко поверење. Додајте забрану као намерно правило са именованим власником, а не као случајност недостајуће конфигурације, и тестирајте је из оба смера захтевом који би иначе успео. Тест је важан јер дозволу која само недостаје може да врати следећи инжењер који дода руту да поправи неповезану жалбу.

Упишите забрану у запис партнера поред дозвола, да би намера надживела промене особља.

Водите то као заједничку услугу, а не као већи лаптоп

Обнављање тунела, ротација акредитива, капацитет и замена пролаза сада сви постају промене заједничке услуге, што значи да им треба распоред и пут комуникације који појединачни лаптопови никада нису захтевали. Партнерски сертификат који истекне у суботу више није прекид за једног корисника; то је прекид свих сесија тог партнера одједном.

Прихватите ниво само када одбијени захтев између партнера не успе тачно како је предвиђено и када дозвољени захтев запосленог стигне до правог одредишта са правим извором. Уклањање сукоба лаптопова уз очувану границу сваког партнера је цео смисао; дизајн у ком је сваки удаљени префикс достижан са сваког стола само је преместио проблем.

Држите малу табелу са партнером, контекстом, дозвољеним опсезима и власником. То ће бити прво што ће неко затражити током инцидента.