Hogyan éri el egy Azure webalkalmazás a helyszíni VPN-en keresztül

A webalkalmazás kimenő kérése egy olyan dolgozót hagy, akit soha nem lát, olyan forrásból, amelyet nem Ön választott, és az irodai tűzfalnak el kell fogadnia azt. Ez az egész probléma egy mondatban. A regionális virtuális hálózat-integráció elérési utat ad a kérelemnek egy virtuális hálózatba, és a helyek közötti VPN továbbítja azt onnan. Minden, ami utólag elromlik, arról szól, hogy a csomag melyik forrástartományban és melyik útvonalon volt ténylegesen használt.

Amit a dolgozó ténylegesen küld

Az App Service olyan dolgozókon futtatja a kódot, akik az előfizetés hálózati nézetén kívül vannak. Ha a regionális integráció engedélyezve van, a kimenő forgalmat átadják egy delegált alhálózatnak egy virtuális hálózaton ugyanabban a régióban, és a csomag ott jelenik meg, mielőtt folytatódna. Az integráció nem helyezi át az alkalmazást a virtuális hálózatba, és nem módosítja a bejövő címét. Csak a kimenő folyamoknak ad eltérő első ugrást.

Alapértelmezés szerint csak a privát címtér használja ezt az utat, így a szokásos internetes célhelyek továbbra is közvetlenül a dolgozótól távoznak. Mindennek a virtuális hálózaton keresztüli átirányítása külön beállítás és külön döntés, mivel a nyilvános függőségeit is átküldi az alagúton.

A konfigurációs forgalom, például a tárolókép-lehívás indításkor, a saját útválasztási szabályait követi, és meghiúsulhat, miközben az API-hívások sikeresek.

Az integrációs alhálózat az a forrás, amelyet engedélyeznie kell

Az iroda látja az integrációs alhálózat címtartományát, vagy bármit, amire a készülék lefordítja, nem az alkalmazás nyilvános kimenő címeit. Helyezze ezt a tartományt a webhely VPN forgalomválasztóiba és a helyszíni tűzfalszabályba. Ha az alagút házirend-alapú, az azt kihagyó választók eldobják a csomagot még akkor is, ha létezik útvonal.

Ne engedjen egyetlen munkavállalói címet sem, amelyet véletlenül megfigyelt. A példányok a méretezéssel és a platform-karbantartással változnak, és az egyik címre rögzített szabály a legrosszabb pillanatban tönkremegy.

A céloldal legyen szűk: egy szolgáltatás, egy kikötő, egy irány, a visszatérési útvonal kifejezetten engedélyezett.

A társviszony-létesítés és az átjáró továbbítása explicit

Ha a VPN-átjáró egy hub virtuális hálózatban, az integrációs alhálózat pedig egy küllőben helyezkedik el, akkor az elérési útnak engedélyeznie kell az átjáró átvitelét a hub társviszony-létesítésen és a távoli átjáró használatát a küllős társviszony-létesítésen. A peering önmagában továbbítja a forgalmat a két virtuális hálózat között, és semmi több. Az integrációs alhálózat hatékony útvonalain megbizonyosodhat arról, hogy a következő ugrás átjárója valóban ott van.

Az olyan hub-and-spoke kialakítás, amelynek útvonaltáblázata 0.0.0.0/0 értéket küld a tűzfalnak, gyakori változat, és ennek a tűzfalnak ezután saját szabályra van szüksége a helyszíni előtaghoz.

Határozza meg az útvonalat papírra, mielőtt jegyet nyitna a hálózati csapattal, mert így megspórol egy napot a találgatásoktól. Tegye bele a visszatérési irányt a rajzba, mivel ez az, amit az emberek elfelejtenek.

A bejövő privát végpont a másik irány

A privát végpont elérhetővé teszi az alkalmazást a virtuális hálózaton belülről. Semmit nem tesz az alkalmazás kimenő hívásaival az irodába, és a csapatok rendszeresen konfigurálnak egyet, miközben a tényleges követelmény ennek fordítottja volt.

A régebbi dokumentáció leírja az átjáróhoz szükséges integrációt, amely a pont-hely VPN-re épül, amely egy másik szolgáltatás saját követelményekkel. A Microsoft 2027. március 31-re ütemezi a szolgáltatás megszüntetését, és helyette regionális integrációt javasol.

Ne másoljon át egy régi pont-webhely konfigurációt csak azért, mert egy régi példa használta.

Ellenőrizze az alkalmazás saját környezetével

Tesztelés a telepített alkalmazásból, nem a laptopról és nem egy virtuális gépről ugyanabban a virtuális hálózatban. Külön naplózza a megoldott címet, a kapcsolat eredményét és az alkalmazásszintű választ, mivel a DNS-hiba, a TCP időtúllépés és a hitelesítés elutasítási pontja három különböző tulajdonosnál. Ha a névfeloldás sikertelen, javítsa ki a magán DNS-t a virtuális hálózathoz, mielőtt megérintené az alagutat.

A zöld alagút állapota csak azt bizonyítja, hogy az átjáró fenn van. Nem mond semmit a kiválasztókról, a tűzfalszabályokról vagy a DNS-ről.

Ha a kérés végre működik, írja be a forrástartományt, a célportot és a DNS-zónát az alkalmazás runbookjába. A következő személy, aki ezt hibakeresi, az Ön jegyzetéből indul ki, nem pedig az átjáró állapotoldaláról.