Twee publieke IP's op een Azure VPN-VM: wie doen wat

Twee publieke IP's op een Azure VPN-VM skep 'n verwagting wat selde hou: die adres waarmee kliënte verbind, is ook die adres wat webwerwe sien. Drie onafhanklike besluite lewer daardie uitkoms, en net die eerste een gaan oor die tonnellaaier. Die tweede is die gasbron wat vir deurgestuurde kliëntverkeer gebruik word, en die derde is die Azure-uitwaartse metode wat op daardie bron van toepassing is. Verander een en die ander twee bly waar hulle was, so besluit elkeen eksplisiet.

Besluit 1: waar die tonnel eindig

'n Azure publieke IP word aan 'n private IP-konfigurasie op die NIC gekoppel; dit is nie 'n adres wat jy binne die gasbedryfstelsel byvoeg nie. Lees die koppeling eerder as om dit te aanvaar: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. Watter private adres daardie navraag ook al teruggee, dit is die een wat die gas werklik moet hou.

Een NIC kan verskeie IP-konfigurasies dra, so twee publieke adresse vereis nie twee NIC's nie. As die ontwerp wel twee NIC's gebruik, bring elkeen sy eie gasroetes en volgende spronge, en dan het jy 'n roetebesluit bygevoeg eerder as om een te vereenvoudig.

Vir 'n diens met 'n eksplisiete plaaslike binding, bind aan die werklike gas-private adres, nooit aan die publieke plekhouer nie. 'n Wildcard-laaier aanvaar verkeer deur elke IP-konfigurasie wat dit bereik, so beperk die intree met die netwerksekuriteitsgroep en die gasheer-firewall eerder as om te hoop die bindvolgorde besluit.

Besluit 2: watter bron die deurgestuurde kliënt gebruik

Nadat die gateway 'n kliëntversoek ontsyfer, is die pakket wat dit deurstuur 'n ander pakket as die een wat by die VPN-laaier aangekom het. Die gas het deurstuur nodig, 'n firewallbeleid wat die vloei toelaat, en 'n bronadres wat die wolkontwerp toelaat. As jy die binneste kliëntadres vertaal, is daardie vertaalde bron die een wat Azure sal evalueer, nie die kliënt se binneste adres nie.

'n Nou SNAT-reël kan 'n gas-private bron kies, maar dit kan nie 'n stroomaf Azure-vertaling oorheers nie. Kies SNAT wanneer jy per-kliënt verantwoordbaarheid binne die VM nodig het; slaan dit oor wanneer die subnet se uitwaartse ontwerp reeds 'n stabiele publieke bron bied en 'n tweede vertaling net toestand sou byvoeg.

Besluit 3: watter Azure-uitwaartse metode wen

Microsoft dokumenteer 'nuitwaartse voorrangorde: 'n toepaslike roete na 'n toestel of gateway kry prioriteit, en subnet NAT Gateway-konneksie kry prioriteit bo 'n instansievlak publieke IP op die betrokke pad. Daardie ordening is hoekom vertaling na 10.20.0.5 nie bewys dat 'n webwerf 198.51.100.20 sal sien nie. Lees die effektiewe roeteblad, die NAT Gateway-assosiasie en die NIC se publieke IP saam voordat jy die uitgangsontwerp aanvaar.

Hou dieAzure NIC-deurstuurinstellingapart van Linux-deurstuur. Die wolkvlag laat pakkette toe wie se bron of bestemming nie aan die NIC toegewys is nie; dit aktiveer nie net.ipv4.ip_forward nie, en die gasinstelling verleen nie die wolktoestemming nie.

Die tonnelsok het sy eie bronbesluit

WireGuard se Address onder wg-quick wys 'n adres aan die WireGuard-koppelvlak toe; dit is nie 'n buitenste UDP-bindinstruksie nie. Die geënkripteerde sok se bron volg die roeteblad, so 'n beleidsroete of 'n tweede verstek kan dit skuif sonder om die koppelvlakadres te raak.OpenVPN selocal-opsie en UDP multihome werk dieselfde: hulle gaan oor die laaier en sy antwoorde, nie oor die internetbron van elke deurgestuurde kliënt nie.

Bewaar die onderliggende roete wat die tonnel dra, en bevestig dat die kliënt steeds geoutentiseerde antwoorde van die verwagte intree-reëling ontvang. Moenie op adreslysvolgorde as 'n permanente bronkeusebeleid staatmaak nie, want die volgende adres wat by die NIC gevoeg word, kan verander watter een wen.

Wat om te aanvaar, en in watter volgorde

Aanvaar drie resultate afsonderlik. Eerste, 'n eksterne kliënt bereik die beoogde VPN-intree. Tweede, 'n nuwe toegelate versoek van daardie VPN-kliënt verlaat deur die gedokumenteerde internetuitgang. Derde, onbedoelde laaier- en deurstuurpaaie bly geweier. Teken die publiek-na-private koppelings en die gas- en wolk-eienaars van elke besluit op dieselfde plek aan.

'n Suksesvolle tonnel bewys net die eerste deel. Toets die uitgang met 'n nuwe vloei, want 'n gekaste verbinding kan die ou bron nog lank ná die roeteverandering gebruik.