Чаму віртуальная машына з VPN-шлюзам у Azure губляе зваротны шлях
VPN-шлюз у віртуальнай машыне Azure патрабуе, каб UDR, сцяг перасылкі на сеткавай карце і палітыка гасцявой сістэмы ўзгадняліся. Прасачыце адзін запыт філіі праз усе тры.
Віртуальная машына Azure, на якой працуе VPN-шлюз, знаходзіцца ўнутры дзвюх незалежных сістэм рашэнняў. Azure вырашае, адкуль пакет пакідае падсетку, выкарыстоўваючы табліцы маршрутаў і наладу перасылкі сеткавай карты. Уласная аперацыйная сістэма шлюза вырашае, ці будзе ён перасылаць расшыфраваны пакет далей. Тунель, які цалкам падняўся, можа ўсё яшчэ збаіць на другой сістэме, і менавіта там спыняюцца большасць такіх разгортванняў.
Тры ўладальнікі аднаго шляху
Вазьміце сетку філіі 192.168.50.0/24 і падсетку працоўнай нагрузкі 10.0.10.0/24, а шлюз знаходзіцца па адрасе 10.0.0.4 у сваёй падсетцы. Адзін запыт закранае тры асобныя канфігурацыі.
| Decision | Configured in | How it fails |
|---|---|---|
| Where the workload subnet sends branch traffic | Azure route table entry | Traffic leaves the subnet and never reaches the appliance |
| Whether a NIC may accept traffic not addressed to it | Azure NIC IP forwarding | Packets arrive and disappear at the interface |
| Whether the guest forwards decrypted traffic | Guest OS or vendor appliance policy | Tunnel is up, workload is unreachable |
| Whether the workload accepts the source | NSG and service policy | Requests delivered, replies refused |
Кожным радком у большасці арганізацый валодае асобная каманда, і менавіта таму гэтая няспраўнасць звычайна прыходзіць як тры заяўкі замест адной.
Маршрут, які паказвае на шлюз
Звяжыце табліцу маршрутаў з падсеткай працоўнай нагрузкі і дайце прэфіксу філіі наступны крок тыпу Virtual appliance з 10.0.0.4 у якасці адраса. Выкарыстоўвайце дасягальны прыватны адрас шлюза і ніколі ягоны публічны пункт уваходу VPN. Наступны крок мусіць быць адрасам, да якога падсетка працоўнай нагрузкі ўжо можа дабрацца. Пакіньце астатнюю маршрутызацыю працоўнай нагрузкі без змен, калі вы свядома не вырашылі замяніць маршрут па змаўчанні.
Трымайце шлюз у ягонай уласнай падсетцы і пераканайцеся, што маршрут, які накіроўвае трафік філіі да шлюза, не перахоплівае таксама ўласны зыходны шлях шлюза. Такая пятля выглядае як здаровы тунель з нулём адказаў, і гэта вельмі непрыемна адладжваць а 2-й гадзіне ночы.
Сцяг сеткавай карты, які ўсе забываюць
У Azure ёсць налада перасылкі IP для кожнай сеткавай карты, і яна па змаўчанні выключана. Яна існуе таму, што карта, якая перасылае трафік, атрымлівае пакеты, адрасаваныя не ёй, і маўклівае іх скідванне — гэта бяспечнае паводзіны па змаўчанні для ўсіх астатніх.
az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true уключае яе для аднаго інтэрфейсу. Указанні Microsoft па перасылцы на сеткавай карце патрабуюць гэтай налады на кожнай падключанай сеткавай карце, якая перасылае трафік, таму шлюз з адной картай усё роўна павінен мець яе ўсталяванай на гэтай карце.
Гэты сцяг не маршрут і не правіла міжсеткавага экрана. Яго ўключэнне дае дазвол і больш нічога.
Што гасцявая сістэма робіць з расшыфраваным пакетам
Пасля завяршэння тунеля ўласны стэк шлюза прымае наступнае рашэнне. На госту Linux перасылка IPv4 — гэта налада часу выканання, і sysctl -w net.ipv4.ip_forward=1 дзейнічае да наступнага запуску. Захавайце яе ў файле ў /etc/sysctl.d/ замест гэтага. У шлюза вытворцы ёсць свой эквівалент, а інструкцыі для Linux, устаўленыя ў платформу вытворцы, звычайна не робяць нічога.
Палітыка міжсеткавага экрана гасцявой сістэмы зноў асобная, як і група сеткавай бяспекі працоўнай нагрузкі. Дазвол UDP 500 і 4500 да публічнага адраса віртуальнай машыны абараняе тунель; гэта нічога не кажа пра тое, ці можа расшыфраваны запыт філіі дасягнуць порта працоўнай нагрузкі.
Прасачыце адзін запыт і ягоны адказ
Выберыце адзін дазволены паток і прасачыце яго ад пачатку да канца. Філіі патрэбны маршрут для 10.0.10.0/24 праз злучэнне сайта, шлюзу патрэбны шлях дастаўкі да падсеткі працоўнай нагрузкі, а падсетцы працоўнай нагрузкі патрэбны зваротны маршрут да філіі.
Вырашыце зарана, ці захоўвае праект адрас крыніцы філіі, ці пераўтварае яго. NAT змяняе тое, што бачыць працоўная нагрузка, таму яе правілы доступу павінны апісваць менавіта абраную мадэль, а не меркаваны адрас шлюза.
Паспяховае рукапацісканне даказвае адно звяно гэтага ланцуга. Шлях завершаны, калі адказ вяртаецца праз той самы шлюз і ўласная палітыка працоўнай нагрузкі гэта дазваляе.