DNS на крайна точка на AWS Client VPN: защо заковаването на разрешения IP не работи
Заменете името на крайната точка на AWS Client VPN с адреса, който сте разрешили, и тунелът спира да работи по-късно. Запазете експортираното име и случайния му префикс.
Миналата седмица 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 поведението на услугата. Правило, което държи един записан адрес, е снимка с неописан срок на годност. Ако контролът приема само неизменни дестинации, решете тази разлика преди пускането, вместо тихо да кодирате отговор.
Партньор, който се нуждае от фиксиран адрес на източника за заявки след вдигане на тунела, има друго изискване: изход. Това, което един сайт наблюдава, зависи от маршрута на приложението и политиката за split-tunnel, а не от адреса, към който се е свързал клиентът. Трафикът по split-tunnel може изобщо да не докосва 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. Собственият журнал на клиента е единственият източник за средния елемент, затова го запишете по време на опита, а не след това.
| What you see | Usual cause | Next check |
|---|---|---|
| One machine fails, others connect | Pinned address or stale hosts entry on that machine | Diff its profile and hosts file against a working copy |
| Everyone fails at once, no config change | The endpoint address rotated | Confirm the current endpoint configuration with the account owner |
| Tunnel up, internal names fail | Client DNS policy, not endpoint resolution | Inspect the resolver pushed after connection |
Адрес, който отговаря днес, е доказателство за днес; името е това, което услугата поддържа валидно. Запишете наблюдението, изпратете го на този, който притежава крайната точка, и оставете профила да сочи към името.
Два навика за изоставяне: изключване на проверките на сертификата, за да се прескочи заседнал handshake, и натрупване на етикети пред името на крайната точка с надеждата, че един ще се задържи. Етикетът се разрешава през wildcard записа или проблемът е другаде. Ако правилно конфигуриран профил все още се проваля, изпратете точната заявка и събитието за свързване, а не по-дълго име на хост.
Преди да го затворите: профилът все още носи експортираното име на крайната точка, никакъв hosts файл не заковава адреса, remote в журнала на клиента съвпада с текущо разрешаване и правилото на защитната стена назовава крайната точка, а не адрес. Това е и състоянието, което да предадете на следващия човек.