Pse pikë-në-sajt kërkon një gateway Azure VPN të bazuar në rrugë
Një gateway i bazuar në politikë nuk ka ndërfaqe tuneli për rrugët e klientëve. Çfarë duhet rindërtuar, në çfarë radhe dhe cilat kufizime mbijetojnë pas zëvendësimit.
Një gateway i bazuar në politikë ndërton një tunel IPsec të zgjedhur nga përzgjedhësit e trafikut dhe nuk ka ndërfaqe ku t'u dorëzojë rrugët e klientëve. Lidhja pikë-në-sajt është një veçori e rrugëzimit: gateway-i zotëron një pishinë adresash klientësh dhe instalon rrugë drejt atyre klientëve në rrjetin virtual. Pikërisht kjo mospërputhje është arsyeja pse portali nuk shfaq asnjë opsion për ta shtuar. Asgjë në gateway-in ekzistues nuk mund të ndërrohet për të prodhuar ndërfaqen, prandaj ndryshimi është zëvendësim dhe jo redaktim konfigurimi.
Rendi ka më shumë rëndësi se hapat individualë. Nëse sekuenca gabohet, ndërprerja mes sajteve kalon përtej dritares së mirëmbajtjes.
Çfarë bën në të vërtetë një gateway i bazuar në politikë
Një gateway i bazuar në politikë përputh paketat me përzgjedhësit e trafikut të konfiguruar në lidhje dhe i dërgon përputhjet në një tunel të vetëm. Nuk ka ndërfaqe tuneli me adresë dhe askund në rrjetin virtual nuk shfaqet një rrugë për klient individual. Tabela e rrugëve thjesht merr prefikset lokale që tregojnë drejt gateway-it. Ky model mjafton për një lidhje mes sajteve mes dy hapësirave fikse adresash.
Një gateway i bazuar në rrugë funksionon anasjelltas: paraqet një ndërfaqe tuneli, dhe rrugët vendosin çfarë hyn në të. Lidhja pikë-në-sajt dhe çdo dizajn grupi i partnerëve të të cilit ndryshon varen nga ekzistenca e asaj ndërfaqeje.
Pse pishina e klientëve ka nevojë për atë ndërfaqe
Kur një laptop lidhet, gateway-i i cakton një adresë nga pishina pikë-në-sajt. Rrjeti virtual pastaj ka nevojë për një rrugë që thotë se kjo adresë është e arritshme përmes gateway-it. Pa një ndërfaqe tuneli nuk ka asgjë ku të bashkëngjitet ajo rrugë.
Pishina vjen nga një interval që ju caktoni, dhe gateway-i shpërndan prej tij. Nëse ai interval mbivendoset me rrjetin lokal ose me një rrjet virtual të lidhur, konflikti shfaqet vetëm pasi një klient lidhet, që është moment i keq për ta zbuluar. Rezervoni pishinën para se të fillojë migrimi.
Edhe lloji nuk është një rregullim për çdo lidhje. Një gateway ka një lloj të vetëm, dhe çdo lidhje që mban sillet në përputhje me atë, prandaj një dizajn i përzier ka nevojë për një gateway të dytë dhe jo për një lidhje të dytë.
Lloji fiksohet në krijim
Microsoft deklaron se një gateway i rrjetit virtual nuk mund të ndryshohet mes të bazuarit në politikë dhe të bazuarit në rrugë pas vendosjes. Nuk ka komandë konvertimi dhe as ndërprerës në portal. Krijimi i një gateway-i të dytë në të njëjtën nënrrjet nuk është zgjidhje alternative, sepse Azure lejon një gateway për çdo rrjet virtual. Prandaj migrimi është heqje, rindërtim dhe rilidhje.
Kjo përfshin edhe vendimin për SKU në të njëjtin ndërtim. Kalimi në një SKU më të madhe më vonë është një zëvendësim tjetër gateway-i me një ndërprerje tjetër.
Një gateway, një GatewaySubnet
Gateway-i banon në një nënrrjet të quajtur GatewaySubnet, dhe vetëm një gateway e zë atë. Përcaktimi i madhësisë së atij nënrrjeti është pjesë e përgatitjes, sepse një SKU më e madhe kërkon më shumë adresa dhe nënrrjeti nuk mund të zvogëlohet më vonë. Shënoni cilësimet aktuale mes sajteve, çelësin e përbashkët, gateway-in e rrjetit lokal dhe rrugët efektive para se të prekni gjë. Pastaj trajtojeni dritaren si një ndërprerje, sepse tuneli mes sajteve mbetet i fikur derisa lidhja e re të konfigurohet.
Një rend rindërtimi që e mban ndërprerjen të kufizuar: krijoni gateway-in e bazuar në rrugë, rikrijoni lidhjen mes sajteve drejt të njëjtit gateway të rrjetit lokal, konfirmoni tunelin dhe një kërkesë host-mel-host, dhe vetëm pastaj shtoni pikë-në-sajt dhe gjeneroni një paketë të re klienti.
Çfarë nuk rregullon zëvendësimi
Një kufizim i dytë i përket partnerit dhe jo Azure. Një pajisje lokale e bazuar në politikë mund të arrijë vetëm rrjetin virtual me të cilin lidhet, dhe nuk mund të kalojë drejt rrjeteve të tjera lokale ose rrjeteve të tjera virtuale përmes të njëjtit gateway. Zëvendësimi i anës Azure nuk ndryshon atë që partneri mund të zgjedhë.
Nëse kërkesa është vërtet tranzit mes sajteve, përgjigja është një pajisje partnere e bazuar në rrugë ose një topologji ku çdo destinacion përfundon veçmas. Vendosni këtë para se të premtoni një datë, sepse vetëm zëvendësimi i gateway-it nuk do ta ofrojë.
Rendi i veprimeve dhe kontrollave
Verifikoni çdo aftësi veçmas. Së pari statusin e tunelit mes sajteve dhe një kërkesë host-mel-host, pastaj një lidhje pikë-në-sajt dhe një burim privat, pastaj çdo shteg tranziti që dizajni pretendon. Një status i gjelbër i gateway-it provon vetëm që shoqata e sigurisë u ngrit, dhe asgjë më shumë. Mbani kontrollat në atë rend, kështu që një dështim të tregojë fazën që e futi.
Rigjeneroni paketat e klientëve pas çdo ndryshimi topologjie dhe mbani pishinën larg çdo intervali lokal dhe të lidhur. Kufizimet dhe dallimet e SKU-ve janë mbledhur në referencën e cilësimeve të Azure VPN Gateway.