Прыватны DNS працуе ў VPC, але не праз VPN
Прыватнае імя, якое развязваецца ўнутры EC2, але не праз VPN, — гэта праблема шляху рэзалвера. Прачытайце форму адмовы, перш чым правіць запіс зоны.
Прыватнае імя развязваецца з інстанцыі EC2, але не з ноўтбука, падлучанага праз VPN, а зона ў кансолі выглядае правільна. Першы штуршок — адрэдагаваць запіс, і гэта амаль ніколі не з'яўляецца праблемай. Запіс камусьці адказвае; проста не адказвае вашаму ноўтбуку. Розніца паміж двума выклікаючымі ў тым, які рэзалвер яны пытаюць і ці мае гэты рэзалвер падтрыманы шлях у DNS-уяўленне VPC.
Я пачынаю з доказу, што запіс існуе, а астатні час марную на шлях запыту. Гэта розныя сістэмы, і яны адмаўляюць па-рознаму.
Прачытайце форму адмовы, перш чым нешта змяніць
Тры вынікі азначаюць тры розныя рэчы, і адзін запыт іх адрознівае: запусціце dig для імя супраць рэзалвера, які кліент сапраўды выкарыстоўвае.
| What you see | What it usually means | First thing to check |
|---|---|---|
| SERVFAIL, or a timeout after several seconds | No path to the resolver, or the resolver cannot reach AWS | Route to the endpoint and the security policy on port 53 |
| NXDOMAIN from a resolver that did answer | The resolver replied, but the zone is not in its view | Zone association or the forwarding rule for that namespace |
| A public address for an internal name | Split DNS is not in effect for this client | Which resolver the client is configured to use |
Тайм-аўт — гэта сцвярджэнне пра сетку. NXDOMAIN — гэта сцвярджэнне пра DNS-уяўленне. Публічны адказ — гэта сцвярджэнне пра палітыку. Праўка запісу зоны падчас тайм-аўту выкідвае адзіны карысны доказ у справе.
Чаму адрас плюс два ў VPC не з'яўляецца аддаленым рэзалверам
Адрас CIDR плюс два — гэта лакальная служба для рэсурсаў унутры VPC. AWS дакументуе, што перасылка запытаў з лакальных сетак або з DNS-сервераў іншага VPC напрамую на гэты адрас не падтрымліваецца і можа даваць нестабільныя вынікі.
Гэта не азначае, што эксперымент ніколі не выглядае працуючым. Гэта азначае, што паводзіны не з'яўляюцца кантрактам, які можна ўпісаць у скрыпт падтрымкі. Падтрымліваны напрамак — уваходная канцавая кропка Resolver: пара адрасоў унутры вашага VPC, даступная з сеткі, якую вы кантралюеце, якая прымае запыты, што прыходзяць ззвонку AWS.
Будуйце шлях у тым парадку, у якім ён адмаўляе чыста
Павінны існаваць тры пераходы, і кожны мае свой спосаб адмовы.
VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addressesПерасылачу патрэбен маршрут да адрасоў канцавой кропкі праз VPN, і зваротны шлях таксама павінен працаваць. Для звычайнага DNS на порце 53 канцавая кропка адказвае праз UDP і TCP, таму абодва пратаколы павінны быць дазволеныя і абодва павінны перажыць любую праверку стану па шляху.
Затым праверце DNS-уяўленне асобна. Прыватная размешчаная зона бачная толькі тым VPC, з якімі яна звязана, або праз наўмысную дамоўленасць пра сумесны доступ. Даступная канцавая кропка сама па сабе не робіць кожную прыватную зону развязнай у яе кантэксце развязання.
Зыходная канцавая кропка абслугоўвае процілеглы напрамак і не адкажа на запыт, які прыходзіць з вашага ноўтбука.
Праверце з абодвух бакоў
Апытвайце з кліента да перасылача, затым з перасылача да канцавой кропкі. Калі кліент адмаўляе, а перасылач працуе, разрыў паміж гэтымі двума.
Калі адмаўляюць абодва, паглядзіце на палітыку бяспекі канцавой кропкі і на адрас крыніцы, які яна сапраўды бачыць. Перасылач за NAT падае адрас NAT замест VPN-адраса ноўтбука, і адной гэтай розніцы дастаткова, каб запыт адкінулі. Калі абодва працуюць, а праграма ўсё роўна адмаўляе, магчыма, праграма выкарыстоўвае іншы рэзалвер, не той, які вы тэставалі.
Трымайце публічную і прыватную прасторы імёнаў наўмысна асобна. Split DNS — гэта палітыка, якую вы наладжваеце, а не пабочны эфект таго, што адзін запыт выпадкова вярнуў даныя.
Чаго я не стаў бы рабіць
Я не стаў бы дадаваць правіла NAT, якое прымусіла працаваць адзін запыт, і называць гэта праектам.
Я не стаў бы скіроўваць кожнага аддаленага кліента на адрас плюс два толькі таму, што адзін тэст аднойчы вярнуў запіс. І я не стаў бы пашыраць палітыку бяспекі канцавой кропкі на ўвесь пул VPN, калі доступ патрэбен аднаму перасылачу. Калі арганізацыя ўжо трымае ўхвалены перасылач унутры VPC, спачатку прачытайце гэты праект, бо другая канцавая кропка, якую вы дадасце, — тая, якую ніхто не дакументуе.