AWS Client VPN са подељеним тунелом: које руте објавити

Конзола нуди прекидач за подељени тунел, па одлука изгледа као поље за потврду. Није. Оно што стварно стиже до клијента је објављени скуп рута крајње тачке, и та листа одлучује које приватне префиксе користе тунел, да ли општи интернет саобраћај остаје локалан или излази кроз AWS и са којим resolver-ом клијент још може да разговара. Три питања решавају дизајн, и на свако се може лоше одговорити док веза и даље успева.

Заставица подељеног тунела није листа одредишта

AWS описује подељени тунел као додавање рута крајње тачке у клијентову табелу рута при успостављању везе. Рута за приватни VPC ограничава тунел на то одредиште; све остало следи уобичајени пут клијента. Подразумевана рута је другачије упутство са другачијим ефектом, зато документација о подељеном тунелу упозорава на објављивање 0.0.0.0/0 на крајњој тачки конфигурисаној за овај режим: то обично прекида повезаност уместо да је прошири. Табела рута крајње тачке је политика, а клијентова табела рута је резултат који можете прегледати.

Читајте табелу рута крајње тачке и инсталиране руте клијента заједно. Ознака описује намеру; руте описују шта се дешава.

Прва одлука: треба ли општи интернет саобраћај да остане локалан?

Ако претраживање треба да користи корисникову сопствену везу, објавите само приватна одредишта која посао тражи и ту станите. Не додајте интернет руту зато што је водич за пуни тунел укључивао једну и не претпостављајте да додатна рута побољшава безбедност. Она мења пут, не додаје политику и обично кошта латенцију коју нисте планирали.

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

Друга одлука: који приватни префикси и чијом ауторизацијом?

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

Тестирање једне успешне сесије доказује један пут. Проверите сваку повезану подмрежу, јер је повезивање подмреже додато касније управо место где обично живи рута која недостаје.

Када одредиште мора бити доступно по имену, имајте на уму да је следеће питање разрешавање имена, а не рута.

Трећа одлука: који resolver следи тунел?

Клијент може да добије DNS сервер доступан само кроз VPN, а тај resolver ради само ако је његова адреса унутар ауторизоване руте. Проверите обе половине: адреса resolver-а следи објављену руту и сервер одговара на имена која апликација тражи. Захтев који успева по адреси док име хоста не успева упућује на именовање, а не на усмеравање, и отклањање грешака тунела у том случају троши поподне.

Јавна имена треба да се разреше као пре везе, што је још један разлог да будете прецизни у вези са оним што објављујете.

Промените скуп рута, затим проверите оба света

AWS документује да промена рута на крајњој тачки са подељеним тунелом ресетује клијентске везе. Планирајте промену имајући то на уму: примените је, поново се повежите кроз подржани клијент и поново прочитајте инсталиране руте уместо да верујете стању примењеном пре измене. Застарело примењено стање је најчешћи разлог зашто исправна промена изгледа покварено.

Прихватите дизајн само када се један приватни ресурс и једно јавно одредиште понашају како је предвиђено, по имену и по адреси, на породицама адреса које стварно подржавате. Тунел који се аутентификује није исто што и тунел који исправно дели саобраћај.

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