Pam nad yw Azure Point-to-Site VPN yn newid eich IP gyhoeddus
Dim ond llwybrau rhwydwaith rhithwir y mae twnnel point-to-site yn eu cario, felly mae eich IP gyhoeddus yn aros yn lleol nes bod tunelu gorfodol a SNAT y wal dân yn symud yr allanfa i Azure.
Rwy'n cysylltu cleient Azure VPN ar liniadur Windows, yn agor tudalen adlais cyfeiriad, ac yn gweld yr un cyfeiriad cyhoeddus a roddodd fy router cartref. Yn y cyfamser mae'r blwch naid yn 10.20.0.4 yn ateb ac mae enw pwynt terfyn preifat yn datrys, felly nid yw'r twnnel wedi torri. Mae porth point-to-site yn gwneud yn union yr hyn y mae ei ffurfweddiad rhagosodedig yn ei ddweud: cario'r rhagddodiaid preifat a gadael popeth arall ar y cyswllt lleol. Mae cael cyfeiriad allanfa sy'n eiddo i Azure yn newid i ddyluniad llwybro, nid yn atgyweiriad.
Yr hyn y mae'r porth yn ei hysbysebu yn rhagosodedig
Mae'r porth yn gwthio llwybrau ar gyfer gofod cyfeiriad y rhwydwaith rhithwir, ynghyd â rhwydweithiau cyfoed lle caniateir tramwy porth a rhagddodiaid lleol a ddysgwyd dros gysylltiad safle-i-safle neu BGP. Nid oes 0.0.0.0/0 yn y set honno. Mae eich system weithredu yn cadw ei llwybr rhagosodedig ar Wi-Fi neu Ethernet, felly nid yw pecyn i API cyhoeddus byth yn mynd i mewn i'r twnnel.
Mae'r cyfeiriad y mae cleient yn ei gael y tu mewn i'r twnnel yn les breifat o'r pwll point-to-site. Mae'n adnabod y cleient i adnoddau yn y VNet; nid yw'n gyfeiriad y gall y rhyngrwyd ei weld, ac ni fydd byth yn ymddangos fel ffynhonnell cais allanol i API SaaS. Ni all cofnod rhestr a ganiateir a adeiladwyd o amgylch y les honno weithio, faint bynnag y byddwch yn aros iddo ymddangos yng nghofnodion y gwerthwr.
Twnnel hollt a thunelu gorfodol ochr yn ochr
| Split tunnel, the default | Forced tunneling | |
|---|---|---|
| Internet traffic exits through | local ISP or office router | firewall or appliance inside Azure |
| Source address the API sees | your home or office IP | the firewall public IP |
| Inspection and logging in Azure | none | policy rules plus flow logs |
| Ongoing cost | gateway only | gateway, firewall hours, data processing |
| What usually breaks | nothing on the egress path | DNS, on-premises routes, overlapping local ranges |
Dim ond yr ail res sy'n newid y cyfeiriad y mae gwasanaeth o bell yn ei weld. Mae popeth arall yn y tabl hwnnw'n gost ac yn arwyneb gweithredol a dderbyniwch pan fo'n rhaid archwilio neu gyfieithu allanfa y tu mewn i Azure. Os bydd rhywun yn gofyn i chi wneud i'r IP cyhoeddus newid, mae'n gofyn am y golofn gyfan ar y dde, nid am addasiad i'r cleient.
Mae opsiwn canolog sy'n werth ei enwi cyn i chi ailadeiladu unrhyw beth. Mae VM dirprwy neu borth y tu mewn i'r VNet yn rhoi cyfeiriad ffynhonnell rheoledig i chi ar gyfer y cymwysiadau y gellir eu cyfeirio ato, heb symud llwybr rhagosodedig y cleient. Mae hynny'n cadw pori arferol yn lleol ac yn dal i fodloni partner sydd ond angen un alwad API i gyrraedd o Azure. Mae'n methu pan fo'r gofyniad mewn gwirionedd yn ymwneud â'r holl draffig, oherwydd mae unrhyw beth sy'n anwybyddu'r gosodiad dirprwy yn dal i adael yn lleol.
Gwnewch i'r twnnel gario'r llwybr rhagosodedig
Ar borth rhwydwaith rhithwir, y ffordd a gefnogir i lywio holl draffig rhyngrwyd y cleient i'r twnnel yw ychwanegu llwybrau personol at y ffurfweddiad point-to-site. Mae dau hanner yn cwmpasu holl ofod IPv4, ac mae pob un yn fwy penodol na'r llwybr rhagosodedig lleol, felly mae'r cleient yn eu ffafrio heb ddileu dim:
Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1Mae'r llinell honno'n ddarluniadol yn hytrach nag yn barod i'w chopïo: cewch wrthrych y porth yn gyntaf gyda Get-AzVirtualNetworkGateway a rhowch ef yn lle GWOBJ, a chadarnhewch fod y SKU a'r model defnyddio yn derbyn llwybrau personol cyn ei redeg. Mae'r un rhagddodiaid yn ymddangos yn y porth ar dudalen ffurfweddiad point-to-site, sef y man mwy diogel i'w gosod os nad ydych eisoes yn sgriptio'r porth.
Mae newid y rhagddodiaid hynny'n ddi-rym y pecyn cleient. Lawrlwythwch becyn cleient VPN eto a'i ailosod, oherwydd mae'r llwybrau'n teithio y tu mewn i'r proffil. Mae cleient sy'n ailgysylltu â'i hen broffil yn cadw'r hen set llwybrau, a gallwch golli awr yn dadfygio newid na chyrhaeddodd ef byth.
Mewn canolbwynt WAN rhithwir diogel, y cyfatebol yw llwybr rhagosodedig yn nhabl llwybrau'r canolbwynt a gysylltir â'r porth point-to-site, gydag Azure Firewall yn y canolbwynt yn cymryd y traffig. Mae'r wal dân yn cyfieithu cysylltiadau sy'n mynd i'r rhyngrwyd i'w gyfeiriadau IP cyhoeddus ei hun, a dyna lle mae'r cyfeiriad allanfa newydd yn dod. Pan fo gan wal dân sawl IP cyhoeddus, gall unrhyw un ohonynt ymddangos fel y ffynhonnell, felly rhaid i restr a ganiateir gynnwys pob un.
Mae'r ddau ddyluniad uchod yn IPv4. Nid yw'r ddau ragddodiad /1 yn gwneud dim i IPv6, ac mae cymorth IPv6 point-to-site mor gul fel y dylech brofi'r cyfuniad cyn addo cydraddoldeb.
Gwiriwch y llwybr, yna'r allanfa
Ar ôl ailosod y pecyn ac ailgysylltu, cadarnhewch fod y cleient wedi gosod y haneri mewn gwirionedd. Ar Windows dylai Get-NetRoute -DestinationPrefix 0.0.0.0/1 a'r un ymholiad ar gyfer 128.0.0.0/1 enwi'r rhyngwyneb twnnel, ac mae route print yn dangos y ddau wrth ymyl eich llwybr rhagosodedig gwreiddiol. Ar Linux rhaid i ip route show restru'r ddau ragddodiad; os nad yw, ni chariodd y proffil hwy byth.
Yna ailwirio'r cyfeiriad cyhoeddus o'r cleient a darllen cofnod y wal dân ar gyfer yr un cysylltiad. Dylai'r ffynhonnell fod yn IP cyhoeddus y wal dân gyda phorth wedi'i gyfieithu. Mae cleient sy'n dal i adael yn lleol tra bo'r ddau lwybr yn bodoli'n golygu bod pecynnau wedi cyrraedd Azure ac wedi gadael trwy lwybr arall: llwybr a ddiffiniwyd gan y defnyddiwr ar is-rwydwaith y porth, wal dân sydd ei hun yn dwnelu'n orfodol i'r safle lleol, neu bolisi sy'n gollwng y llif cyn cyfieithu.
Ailbrofwch un cyrchfan breifat yn yr un sesiwn. Mae gwesteiwr naid sy'n stopio ateb ar ôl y newid yn arwydd arferol bod y rhagddodiaid newydd wedi disodli rhywbeth, naill ai llwybr lleol culach a hysbysebwyd o'r blaen neu ddatrysiad enwau sy'n mynd nawr i ddatryswr heb anfonwr ymlaen ar gyfer eich parthau preifat.
Pryd i adael y twnnel hollt yn llonydd
Os mai'r nod yw cyrraedd API preifat, pwynt terfyn preifat neu dudalen weinyddu fewnol yn unig, mae'r ymddygiad rhagosodedig yn rhatach ac yn dawelach. Mae tunelu gorfodol yn ychwanegu oriau wal dân a chostau prosesu data, llwybr hirach, ac un man arall lle gall pob llif cleient fethu. Mae hefyd yn dal llawer mwy o draffig na'r un gyrchfan yr oeddech yn poeni amdani.
Estynnwch amdano pan fydd y gofyniad wedi'i fynegi yn nhermau allanfa: rhaid i bartner weld cyfeiriad Azure sefydlog, mae diogelwch eisiau i'r cysylltiadau gael eu cofnodi a'u harchwilio, neu rhaid i ddata adael trwy un pwynt rheoledig. Hyd yn oed wedyn mae'r dyluniad yn rhoi allanfa ranedig i bob defnyddiwr, felly rhaid i atebolrwydd fesul defnyddiwr ddod o hunaniaeth yn y cymhwysiad yn hytrach nag o'r cyfeiriad ffynhonnell.
Cyn i chi gau'r newid, cadarnhewch bedwar peth: y pecyn cleient sydd wedi'i osod yw'r un newydd, mae'r ddau lwybr /1 ar ryngwyneb y twnnel, mae cyrchfan breifat yn dal i ateb, ac mae cofnod y gwasanaeth o bell yn dangos cyfeiriad y wal dân.