Azure UDR egy VPN-átjáró felé: egy cél, nem a teljes kimenő forgalom

Hozzáad egy felhasználó által definiált útvonalat egy külső előtaghoz, a VPN-átjáróra irányítja, és a forgalom mégis az Azure internetes útvonalán távozik. Vagy helyesen távozik, és a válasz soha nem jön vissza. Mindkét eredmény ugyanabból a hibából származik: az Azure következő ugrását tekinteni az egész tervezésnek. Az útvonaltábla csak azt dönti el, melyik kijáratot veszi egy csomag az Azure-n belül. Hogy mi történik vele az alagút után, és hogyan tér vissza a válasz, az a második fele, amit meg kell építenie.

A következő ugrás egy átjáró, nem egy eszköz IP-je

Az UDR egy megfelelő előtagot küld egy következő ugrás típusnak, és a VirtualNetworkGateway egy típus, nem cím. Az emberek beillesztik az átjáró privát IP-jét egy VirtualAppliance útvonalba, majd azon tűnődnek, miért nem egyezik semmi, mert ez a típus inkább egy NIC-et vagy egy belső terheléselosztót vár. A Microsoft útválasztási dokumentációja is az átjáró következő ugrását olyan virtuális hálózatra korlátozza, amelynek átjárója VPN-átjáró. Az ExpressRoute, a Route Server és a Virtual WAN hub nem címezhető ezzel az opcióval.

Ellenőrizze, mi van valójában a virtuális hálózatban, mielőtt megírja az útvonalat. Ha a tervezés hubon keresztül irányít, az útvonal a hub útválasztási tulajdonosáé, nem azé a spoke-é, amelyet éppen szerkeszt.

Olvassa el az érvényes útvonalat, mielőtt bármit módosít

Az Azure rendszerútvonalakat, BGP-n keresztül tanult előtagokat és UDR-eket egyesít egy NIC-nkénti érvényes útvonaltáblába, és a leghosszabb egyező előtag nyer, függetlenül attól, honnan származik. Ugyanarra az előtagra az UDR legyőzi a BGP-útvonalat. Ez a sorrend az oka annak, hogy egy korábbi kísérletből maradt elavult UDR csendben felülírhatja az előtagot, amelyet éppen most tanult meg az alagúton keresztül.

Először nézze meg az érvényes táblát, majd döntse el, hozzáad-e egy útvonalat, vagy lecserél egyet:

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

Olvassa el a forrás oszlopát is, ne csak az előtagot. A helyes előtagú és rossz forrású útvonal megmondja, melyik objektumot kell szerkeszteni, és megkíméli attól, hogy hozzáadjon egy második útvonalat, amely veszít az elsővel szemben.

Írja meg az útvonalat a valódi előtaghoz és alhálózathoz

Használja a cél valódi előtagját, abból a szolgáltatásból véve, amelyet ténylegesen elér, egy fórumbejegyzésből másolt nyilvános tartomány helyett. Kezdje egy jóváhagyott szolgáltatással, mielőtt olyan alapértelmezett útvonalat fontolna meg, amely az összes kimenő forgalmat áthelyezi. Ezután csatolja az útvonaltáblát a munkaterhelés alhálózatához. Az átjáró alhálózatának saját követelményei vannak, és a tábla ott csatolása az átjárót töri el ahelyett, hogy a munkaterhelést irányítaná.

Hozza létre az útvonalat, majd kösse a táblát ahhoz az alhálózathoz, amely a munkaterhelést tárolja:

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

A propagáció is számít. Ha azon a táblán engedélyezett a BGP-propagáció, a tanult előtagok a sajátjai mellett jelennek meg, és egy konkrétabb tanult előtag legyőzhet egy szélesebb UDR-t. Csak akkor tiltsa le a propagációt, ha azt szeretné, hogy az UDR-készlet legyen mérvadó azon alhálózat számára.

Fejezze be a helyszíni felét, különben a folyam ott meghal

A helyszíni átjárónak el kell fogadnia az Azure-forrást, továbbítania kell a célhoz, és engedélyeznie kell az alkalmazást. Továbbvezető útja lehet internetes kijárat vagy más privát ugrás, de ez a döntés a tervbe tartozik, nem az Azure-útvonaltáblába. A szokásos hiba a visszaút. Egy internetes cél nem irányítja vissza a privát Azure-forrást Önhöz, így a válasz a saját alapértelmezett átjárójára megy és meghal, vagy egyáltalán nem távozik.

Két tervezés oldja meg ezt, és nem felcserélhetők. Fordítsa le a forrást a kijáratnál, hogy a cél egy nyilvános címre válaszoljon, amely a helyszíni hálózat tulajdonában van. Vagy őrizze meg a forrást, és építsen irányított visszatérési kapcsolatot, hogy a válaszok az alagúton keresztül térjenek vissza. Válasszon egyet, és írja le, melyik címet fogja látni az alkalmazás.

A szelektorok és az engedélyezési listák mindettől különállók. Az Azure következő ugrásának kiválasztása nem szélesíti a VPN-forgalom szelektorait, és nem változtatja meg egy külső szolgáltatás forrásengedélyezési listáját.

Ellenőrizze a cél által látott forrással

Küldje a kérést a valódi munkaterhelésből, ne egy másik alhálózat ugrógazdájából, majd olvassa le a forráscímet, amelyet a cél látott. Ez az egyetlen érték megmondja, melyik a két visszatérési tervezés közül. Ezután ellenőrizze a válasz útvonalát, és erősítse meg, hogy a VM-hez irányuló szokásos kezelési forgalom továbbra is működik, mert a véletlenül hozzáadott alapértelmezett útvonal jóval korábban mutatkozik megszakadt SSH-munkamenetként, mint hibás alkalmazásként.

A kiválasztott előtagon keresztüli tranzit sokkal szűkebb változás, mint a kényszerített alagutazás. Tartsa szűken, és a visszaállítás egyetlen útvonal törlése.