Waarom Azure Point-to-Site VPN jou publieke IP nie verander nie

Ek koppel die Azure VPN-kliënt op ’n Windows-skootrekenaar, maak ’n adres-eggopblad oop en sien dieselfde publieke adres wat my tuisroeteerder uitgedeel het. Intussen antwoord die sprongkas by 10.20.0.4 en ’n private-eindpuntnaam los op, so die tonnel is nie stukkend nie. ’n Point-to-Site-hek doen presies wat sy verstekopstelling sê: dit dra die private voorvoegsels en laat alles anders op die plaaslike skakel. Om ’n Azure-eie uitgangsadres te kry, is ’n verandering van roetebeplanning, nie ’n herstelling nie.

Wat die hek by verstek adverteer

Die hek stoot roetes vir die virtuele netwerk se adresruimte, plus gepeerde netwerke waar hekdeurvoer toegelaat word en plaaslike voorvoegsels wat oor ’n werf-tot-werf-verbinding of BGP geleer is. Daar is geen 0.0.0.0/0 in daardie stel nie. Jou bedryfstelsel hou sy verstekroete op Wi-Fi of Ethernet, so ’n pakkie na ’n publieke API betree nooit eers die tonnel nie.

Die adres wat ’n kliënt binne die tonnel ontvang, is ’n private huurkontrak uit die Point-to-Site-poel. Dit identifiseer die kliënt vir hulpbronne in die VNet; dit is nie ’n adres wat die internet kan sien nie, en dit sal nooit as die bron van ’n uitgaande versoek na ’n SaaS-API verskyn nie. ’n Toelaatlys-inskrywing wat om daardie huurkontrak gebou is, kan nie werk nie, hoe lank jy ook al wag dat dit in die verskaffer se logs verskyn.

Verdeelde tonnel en gedwonge tonneling langs mekaar

Net die tweede ry verander die adres wat ’n afgeleë diens sien. Alles anders in daardie tabel is koste en bedryfslas wat jy aanvaar wanneer uitgang binne Azure ondersoek of vertaal moet word. As iemand jou vra om die publieke IP te laat verander, vra hy om die hele regterkolom, nie om ’n aanpassing aan die kliënt nie.

Daar is ’n middelweg wat die moeite werd is om te noem voordat jy enigiets herbou. ’n Volmag- of hek-VM binne die VNet gee jou ’n beheerde bronadres vir die programme wat daarheen gerig kan word, sonder om die kliënt se verstekroete te skuif. Dit hou normale blaai plaaslik en bevredig steeds ’n vennoot wat net een API-oproep van Azure af wil ontvang. Dit misluk wanneer die vereiste eintlik oor alle verkeer gaan, want enigiets wat die volmaginstelling ignoreer, vertrek steeds plaaslik.

Laat die tonnel die verstekroete dra

Op ’n virtuele-netwerkhek is die ondersteunde manier om alle kliënt-internetverkeer in die tonnel in te stuur, om pasgemaakte roetes by die Point-to-Site-opstelling te voeg. Twee helftes dek die hele IPv4-ruimte, en elkeen is meer spesifiek as die plaaslike verstekroete, so die kliënt verkies hulle sonder om enigiets te skrap:

Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1

Daardie reël is ter illustrasie eerder as kopieer-en-plak-klaar: haal eers die hek-objek met Get-AzVirtualNetworkGateway en vervang dit vir GWOBJ, en bevestig dat die SKU en ontplooiingsmodel pasgemaakte roetes aanvaar voordat jy dit uitvoer. Dieselfde voorvoegsels verskyn in die portaal op die Point-to-Site-opstellingsblad, wat die veiliger plek is om hulle te stel as jy nie reeds die hek programmeer nie.

Om daardie voorvoegsels te verander, maak die kliëntpakket ongeldig. Laai die VPN-kliëntpakket weer af en installeer dit weer, want die roetes reis binne die profiel. ’n Kliënt wat met sy ou profiel weer koppel, hou die ou roetestel, en jy kan ’n uur verloor om ’n verandering te ontfout wat nooit by hom uitgekom het nie.

In ’n beveiligde virtuele WAN-spilpunt is die ekwivalent ’n verstekroete in die spilpunt se roetetabel wat met die Point-to-Site-hek geassosieer word, met Azure Firewall in die spilpunt wat die verkeer neem. Die firewall vertaal internetgerigte verbindings na sy eie publieke IP-adresse, en daardie vertaling is waar die nuwe uitgangsadres vandaan kom. Wanneer ’n firewall verskeie publieke IP's het, kan enigeen van hulle as die bron verskyn, so ’n toelaatlys moet almal bevat.

Beide ontwerpe hierbo is IPv4. Die twee /1-voorvoegsels doen niks vir IPv6 nie, en Point-to-Site-IPv6-ondersteuning is smal genoeg dat jy die kombinasie moet toets voordat jy gelykheid belowe.

Kontroleer die roete, dan die uitgang

Nadat jy die pakket weer geïnstalleer en weer gekoppel het, bevestig dat die kliënt die helftes werklik geïnstalleer het. Op Windows behoort Get-NetRoute -DestinationPrefix 0.0.0.0/1 en dieselfde navraag vir 128.0.0.0/1 die tonnelkoppelvlak te noem, en route print wys albei langs jou oorspronklike verstek. Op Linux moet ip route show die twee voorvoegsels lys; as dit nie doen nie, het die profiel hulle nooit gedra nie.

Kontroleer dan weer die publieke adres van die kliënt af en lees die firewall-log vir dieselfde verbinding. Die bron behoort die firewall se publieke IP met ’n vertaalde poort te wees. ’n Kliënt wat steeds plaaslik uitgaan terwyl albei roetes bestaan, beteken pakkies het Azure bereik en het langs ’n ander pad vertrek: ’n gebruikergedefinieerde roete op die hek-subnet, ’n firewall wat self gedwing-tonnel na plaaslik is, of ’n beleid wat die vloei voor vertaling laat val.

Toets een private bestemming weer in dieselfde sessie. ’n Spronggasheer wat ná die verandering ophou antwoord is die gewone teken dat die nuwe voorvoegsels iets verdring het, hetsy ’n nouer plaaslike roete wat vroeër geadverteer is of naamoplossing wat nou na ’n oplosser gaan sonder ’n doorstuurder vir jou private sones.

Wanneer om die verdeelde tonnel met rus te laat

As die doel net is om ’n private API, ’n private eindpunt of ’n interne administrasieblad te bereik, is die verstekgedrag goedkoper en stiller. Gedwonge tonneling voeg firewall-ure en dataproesseringkoste by, ’n langer pad, en nog ’n plek waar elke kliëntvloei kan misluk. Dit vang ook veel meer verkeer as die enkele bestemming waaroor jy bekommerd was.

Gryp daarna wanneer die vereiste in terme van uitgang gestel word: ’n vennoot moet ’n vaste Azure-adres sien, sekuriteit wil die verbindings gelog en ondersoek hê, of data moet deur een beheerde punt verlaat. Selfs dan gee die ontwerp elke gebruiker ’n gedeelde uitgang, so per-gebruiker verantwoording moet van identiteit by die toepassing kom eerder as van die bronadres.

Voordat jy die verandering sluit, bevestig vier dinge: die geïnstalleerde kliëntpakket is die nuwe een, die twee /1-roetes sit op die tonnelkoppelvlak, ’n private bestemming antwoord nog, en die afgeleë diens se log wys die firewall-adres.