DNS AWS Client VPN: выкарыстоўвайце resolver VPC, а не падсетку

Endpoint знаходзіцца ў 10.0.8.0/24, таму resolver павінен быць 10.0.8.2. Гэта разважанне я чую найчасцей, і яно памылковае двойчы. Route 53 Resolver адказвае на асноўным дыяпазоне IPv4 VPC плюс два, што для VPC 10.0.0.0/16 — 10.0.0.2, незалежна ад таго, якую падсетку выкарыстоўвае endpoint. Другая памылка цішэйшая: правільны адрас у endpoint не азначае, што аперацыйная сістэма кліента хоць нешта ў яго пытае. Абедзве памылкі даюць аднолькавы сімптом: развязанне імёнаў працуе ў адных кліентаў і не працуе ў іншых.

Міф пачынаецца з прывязкі падсеткі

Прывязка — гэта пра тое, дзе жывуць эластычныя сеткавыя інтэрфейсы для кліенцкіх злучэнняў, а не пра тое, які адрас resolver існуе. Падсеткі endpoint даюць кліентам адрас унутры VPC, і кожная з іх не нясе ўласнага resolver.

Калі раздзяліць гэтыя дзве ідэі, арыфметыка перастае быць загадкавай, а пошук няспраўнасцей пераходзіць да кліента — там большасць такіх выпадкаў і заканчваецца.

Вылічыце адрас з асноўнага дыяпазону VPC

Вазьміце асноўны CIDR IPv4 VPC і дадайце два да адраса сеткі. 10.0.0.0/16 дае 10.0.0.2, 172.31.0.0/16 дае 172.31.0.2, а VPC з другасным дыяпазонам пакідае resolver на асноўным. Падсетка 10.0.8.0/24 унутры гэтага VPC яго не зрушвае. Запішыце адрас побач з ID VPC, перш чым чапаць endpoint, бо лік — уласцівасць VPC, а не злучэння.

VPC таксама адказвае на link-local адрасе 169.254.169.253. Гэты адрас дасяжны знутры VPC, але не з’яўляецца звычайнай маршрутызаванай мэтай для ноўтбука на іншым канцы тунеля.

Такім чынам, ёсць два сапраўдныя адрасы resolver, і ні адзін з іх не падсетка плюс два.

Што робіць налада endpoint і чаго не робіць

Endpoint Client VPN мае палі DNS-сервера, і там, дзе кансоль прапануе варыянт resolver VPC, яна запаўняе тую ж ідэю. Іх усталяванне змяняе тое, што сэрвіс перадае кліентам падчас усталявання злучэння. Гэта не змяняе тое, што робіць з гэтым значэннем некіраваны кліент OpenVPN, бо кліент усё яшчэ павінен ужыць яго да аперацыйнай сістэмы. Менавіта з гэтай прагаліны паўстае «працуе на маім Mac, але не на Linux-машыне».

У Linux інтэграцыя resolver належыць мэнэджару злучэнняў, а не карыстальніку. Ручное рэдагаванне /etc/resolv.conf даказвае, што адрас працуе для адной сесіі, а затым знікае пры перападключэнні — таму столькі выпраўленых выпадкаў вяртаецца наступнай раніцай.

Праверце актыўны resolver на кліенце пасля падключэння, а не старонку канфігурацыі endpoint.

Split tunneling можа перашкодзіць правільнаму resolver

Пры split tunneling выкарыстоўваюцца толькі маршруты, прасунутыя ў тунель. Калі адрас resolver не пакрыты маршрутам, запыт выходзіць праз лакальны інтэрфейс і на яго адказвае ваш хатні роўтар. Адрас у endpoint усё яшчэ правільны, і пошук усё яшчэ не ўдаецца. Дадайце маршрут для resolver і праверце зноў.

Перакрыжаваныя лакальныя дыяпазоны даюць той жа вынік горшым чынам: на запыт адказваюць, проста не той сервер.

Не адкрывайце групы бяспекі для адраса Amazon DNS

Інстынкт пры тайм-аўце пошуку — дадаць правіла, якое дазваляе UDP 53 да адраса resolver. AWS дакументуе, што групы бяспекі і сеткавыя ACL не фільтруюць трафік Amazon DNS так, як фільтруюць трафік да ўласнага экзэмпляра DNS. Адкрыццё гэтых правілаў нічога не змяняе для resolver VPC і пашырае мяжу без прычыны. Resolver, які вы трымаеце самі, — іншы выпадак, і яму сапраўды патрэбныя свае правілы.

Калі ў вашай архітэктуры ёсць абодва, праверце, на які з іх накіраваны кліент, перш чым правіць любое правіла.

Праверце шлях, потым вымерайце нешта іншае

Развяжыце публічнае імя, развяжыце прыватнае імя, зарэгістраванае ў прыватнай хост-зоне, звязанай з VPC, і паміж гэтым прачытайце актыўны resolver кліента. Такая паслядоўнасць аддзяляе «адрас resolver няправільны» ад «зона не звязана» і ад «кліент праігнараваў наладу». У кожнага свая праўка, і ні адзін з іх не праблема прапускной здольнасці.

Паспяховы пошук нічога не кажа пра ўстойлівую хуткасць перадачы, таму трымайце гэтыя дзве размовы асобна, калі будзеце рапартаваць.