DNS на крајната точка на AWS Client VPN: зошто фиксирањето на решената IP адреса не функционира

Минатата недела dig +short ви даде една адреса за името на крајната точка во вашиот AWS Client VPN профил, и тунелот се поврза. Оваа недела истиот профил стои на 'Connecting' на вашиот лаптоп, додека недопрената копија на колегата сè уште работи. Ништо не беше блокирано и сертификатот не истече. Некој го замени името на домаќинот на крајната точка со таа решена адреса, и услугата повеќе не одговара таму. Извезеното име е делот изграден да го преживее тоа менување.

Името во вашиот профил може да не е името што се бара

Профилите извезени од Client VPN обично содржат remote-random-hostname. Кога таа опција е вклучена, клиентот создава еднократна ознака, ја спојува со името на крајната точка со точка и го решава комбинираното име. Запис со џокер во зоната на крајната точка одговара на која било ознака, затоа измислен префикс сè уште се решава и затоа трикот останува невидлив кога барањето го повторувате рачно.

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

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

Зошто зачуваниот одговор не може да остане точен

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

Истиот одговор во /etc/hosts го наследува истиот рок со дополнителен проблем. Записот hosts преживува рестартирања, повторни извезувања и поправки 'преинсталирај го клиентот', па дефектот се враќа секогаш кога адресата се преместува. Видов еден како недели лежи безопасно, а потоа ги исклучува сите машини што го носат, додека свежите инсталации се поврзуваа нормално. Тоа разделување, една група паѓа а друга е во ред на истата сметка, е најевтината трага што ќе ја добиете.

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

Што проверува услугата кога тунелот се подига

Client VPN бара адресата на која сте поврзани да се совпаѓа со адреса решена за DNS името на крајната точка. Тоа едно барање објаснува неколку дефекти што изгледаат неповрзани: прилагоден DNS запис што покажува на друго место, прилагоден frontend што препраќа кон вистинската адреса на крајната точка, и профил препишан на сурова адреса. AWS го документира распоредот прилагоден запис плус препраќање како дефект со понови клиенти од AWS. Проверката е тесна; тоа не е пресуда дека секој алијас е забранет.

Тоа не е ни општо правило за VPN протоколи. Бројчен remote е сосема валиден во обично OpenVPN распоредување, и многу работат така. Ограничувањето доаѓа од управуваниот распоред, не од протоколот под него.

Што го прави олабавувањето на проверката на сертификатот погрешен рефлекс. Ако профилот падне по замена на адресата, исклучувањето на проверката на серверот ја преместува грешката наместо да го поправи решавањето или барањето за совпаѓање на адресата, и остава клиент што ќе верува на сè. Чувајте го извезениот CA, проверката на серверот и поставките за взаемна автентикација точно како што дојдоа.

Списоците за дозвола, излезот и приватниот DNS се три одделни проблеми

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

Партнерот на кого му треба фиксна изворна адреса за барања по подигањето на тунелот има друго барање: излез. Она што го гледа една веб-страница зависи од рутата на апликацијата и политиката на поделен тунел, не од адресата на која се поврзал клиентот. Сообраќајот на поделениот тунел може воопшто да не ја допре AWS.

Приватниот DNS внатре во тунелот е трет слој. Решавачот даден на клиентите одговара на внатрешни имиња по поврзувањето; тој не може да ја реши јавната крајна точка пред тунелот да постои. Дефектот при решавање на крајната точка и дефектот при решавање на внатрешна апликација се случуваат во различни фази, а нивното мешање ве носи до погрешен дневник.

Семејството адреси припаѓа на истиот список. Одговорот IPv4 не кажува ништо за дозволената патека на крајна точка IPv6 или со двоен стек, па снимката направена во едно семејство не е доказ за другото.

Проверете врска без да фиксирате ништо

Започнете од профилот како што е извезен и прочитајте што навистина бара:

grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'

Потоа споредете три работи: името на крајната точка што го држи профилот, адресата што клиентот ја пријавува за нов обид и во што се решава името сега. Името што се решава докажува само дека записот одговара; транспортот и автентикацијата се одделни и крајната точка не мора да одговори на ping. Сопствениот дневник на клиентот е единствениот извор за средната ставка, затоа забележете го за време на обидот, а не потоа.

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

Две навики да се остават: исклучување на проверките на сертификатот за да се помине заглавено handshake, и натрупување ознаки пред името на крајната точка со надеж дека една ќе се залепи. Ознаката се решава преку записот со џокер или проблемот е на друго место. Ако правилно конфигуриран профил сè уште паѓа, испратете го точното барање и настанот на поврзување, не подолго име на домаќин.

Пред да го затворите: профилот сè уште го носи извезеното име на крајната точка, ниту една датотека hosts не ја фиксира адресата, remote во дневникот на клиентот се совпаѓа со тековно решавање и правилото на огнениот ѕид го именува крајната точка, а не адреса. Тоа е и состојбата што треба да му се предаде на следниот човек.