Які зыходны IP выкарыстоўвае шлюз NAT у AWS пры руху да VPN?

Вы адкрываеце кансоль VPC, бо партнёр спытаў, які дыяпазон крыніц прыйдзе праз VPN «сайт-сайт». Старонка шлюзаў NAT паказвае публічны шлюз з прывязаным эластычным IP, і спакуса — адправіць гэты адрас і спыніцца. Гэта правільны адказ для інтэрнэт-шляху і няправільны для шляху праз VPN, а розніца ў тым, на які шлюз паказвае табліца маршрутаў. Прайдзіце маршрут, перш чым пісаць спіс дазволаў.

Пачніце са старонкі шлюзаў NAT, а не са спіса дазволаў

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

Спачатку прачытайце тып, бо публічны ці прыватны вырашае, ці з’явіцца пазней у ланцугу інтэрнэт-шлюз. Затым прачытайце падсетку, бо менавіта там жыве другі маршрут.

Прасачыце два пераўтварэнні

І публічныя, і прыватныя шлюзы NAT пераўтвараюць прыватную крыніцу IPv4 працоўнай нагрузкі ў прыватны адрас IPv4 самога шлюза NAT. Гэта першае пераўтварэнне адбываецца незалежна ад тыпу. Другое пераўтварэнне — тое, пра якое забываюць: публічны шлюз NAT перадае трафік інтэрнэт-шлюзу, які супастаўляе адрас з прывязаным эластычным IP.

workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> internet gateway -> Elastic IP 203.0.113.25
workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> transit or virtual private gateway -> partner sees 10.20.2.10

На прыватным шляху ў ланцугу няма інтэрнэт-шлюза. Калі трафік выходзіць праз транзітны шлюз або віртуальны прыватны шлюз, кіраўніцтва па шлюзах NAT апісвае прыватны адрас шлюза NAT як крыніцу, якую атрымлівае аддалены бок. Менавіта гэты адрас партнёр павінен дазволіць, а не эластычны IP.

Шлях праз VPN звычайна паказвае прыватны адрас

Для працоўнай нагрузкі ў 10.20.1.0/24, якая дасягае прэфікса партнёра, табліца маршрутаў падсеткі працоўнай нагрузкі паказвае на шлюз NAT, а табліца маршрутаў падсеткі шлюза NAT паказвае на шлях прыватнага шлюза. Абодва пераходы важныя, і толькі другі вызначае, што бачыць партнёр. Калі ў падсеткі NAT няма маршруту да шляху праз VPN, пакет ніколі не дасягне мэты, і гэта іншая памылка, чым няправільны зыходны адрас.

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

Калі другое пераўтварэнне змяняе адказ

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

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

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

Напішыце кантракт, па якім ваш партнёр можа дзейнічаць

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

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

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