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 понашање услуге. Правило које држи једну забележену адресу је снимка с неисписаним роком. Ако контрола прихвата само непроменљива одредишта, решите тај јаз пре увођења уместо да тихо кодирате одговор.
Партнеру који треба фиксна изворна адреса за захтеве после подизања тунела треба нешто друго: излаз. Шта веб локација види зависи од руте апликације и политике подељеног тунела, а не од адресе на коју се клијент повезао. Саобраћај подељеног тунела можда уопште не дотиче AWS.
Приватни DNS унутар тунела је трећи слој. Решавач који се даје клијентима одговара на интерна имена после повезивања; не може да реши јавну крајњу тачку пре него што тунел постоји. Квар решавања крајње тачке и квар решавања интерне апликације догађају се у различитим фазама, а њихово мешање води вас у погрешан дневник.
Адресна породица припада истом списку. IPv4 одговор не говори ништа о дозвољеној путањи IPv6 или dual-stack крајње тачке, па снимка узета у једној породици није доказ за другу.
Проверите везу без фиксирања ичега
Почните од профила како је извезен и прочитајте шта заправо тражи:
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 и гомилање ознака испред имена крајње тачке у нади да ће се једна задржати. Ознака се решава кроз запис с џокером или је проблем негде другде. Ако исправно конфигурисан профил и даље не успева, пошаљите тачан упит и догађај повезивања, а не дуже име домаћина.
Пре него што то затворите: профил још носи извезено име крајње тачке, ниједна hosts датотека не фиксира адресу, remote у дневнику клијента одговара тренутном решавању и правило заштитног зида именује крајњу тачку, а не адресу. То је и стање које треба предати следећој особи.