Dy IP publike në një VM VPN Azure: cili bën çfarë

Dy IP publike në një VM VPN Azure krijojnë një pritje që rrallë përmbushet: adresa me të cilën lidhen klientët do të jetë edhe adresa që shohin faqet web. Tre vendime të pavarura e prodhojnë atë rezultat, dhe vetëm i pari ka të bëjë me dëgjuesin e tunelit. I dyti është burimi i mysafirit që përdoret për trafikun e klientit të përcjellë, dhe i treti është metoda e daljes së Azure që zbatohet për atë burim. Ndryshoni një dhe dy të tjerat mbeten ku ishin, prandaj vendosni secilin në mënyrë të qartë.

Vendimi 1: ku përfundon tuneli

Një IP publike e Azure lidhet me një konfigurim IP privat në NIC; nuk është një adresë që shtoni brenda sistemit operativ të mysafirit. Lexoni hartëzimin në vend që ta supozoni: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. Cilado adresë private që kthen ai pyetje, është ajo që mysafiri duhet të ketë në të vërtetë.

Një NIC mund të mbajë disa konfigurime IP, kështu që dy adresa publike nuk kërkojnë dy NIC. Nëse dizajni përdor vërtet dy NIC, secili sjell rrugët e veta të mysafirit dhe hapat e ardhshëm, dhe keni shtuar një vendim rrugëtimi në vend që ta thjeshtonit.

Për një shërbim me lidhje lokale të qartë, lidhuni me adresën reale private të mysafirit, kurrë me zëvendësuesin publik. Një dëgjues që pranon të gjitha adresat merr trafik përmes çdo konfigurimi IP që e arrin, prandaj kufizoni hyrjen me grupin e sigurisë së rrjetit dhe murin e zjarrit të hostit në vend që të shpresoni se do të vendosë rendi i lidhjes.

Vendimi 2: cilin burim përdor klienti i përcjellë

Pasi porta të deshifrojë një kërkesë të klientit, paketa që përcjell është e ndryshme nga ajo që mbërriti në dëgjuesin VPN. Mysafiri ka nevojë për përcjellje të aktivizuar, një politikë muri zjarri që lejon rrjedhën dhe një adresë burimi që e lejon dizajni i resë. Nëse përktheni adresën e brendshme të klientit, është pikërisht ai burim i përkthyer që Azure do të vlerësojë, jo adresa e brendshme e klientit.

Një rregull i ngushtë SNAT mund të zgjedhë një burim privat të mysafirit, por nuk mund të mbizotërojë një përkthim të mëvonshëm të Azure. Zgjidhni SNAT kur ju nevojitet përgjegjshmëri për çdo klient brenda VM-së; hiqni dorë kur dizajni i daljes së nënrrjetit siguron tashmë një burim publik të qëndrueshëm dhe një përkthim i dytë do të shtonte vetëm gjendje.

Vendimi 3: cila metodë e daljes së Azure fiton

Microsoft dokumentonrendin e përparësisë së daljes: një rrugë e zbatueshme drejt një pajisjeje ose porte ka përparësi, dhe lidhja e nënrrjetit përmes NAT Gateway ka përparësi ndaj një IP publike në nivel instance në rrugën përkatëse. Ky rend është arsyeja pse përkthimi në 10.20.0.5 nuk provon që një faqe web do të shohë 198.51.100.20. Lexoni së bashku tabelën efektive të rrugëve, shoqërimin me NAT Gateway dhe IP publike të NIC përpara se të pranoni dizajnin e daljes.

Mbajenicilësimin e përcjelljes së NIC të Azuretë ndarë nga përcjellja në Linux. Flamuri i resë lejon paketa që burimi ose destinacioni i të cilave nuk është caktuar NIC; ai nuk aktivizon net.ipv4.ip_forward, dhe cilësimi i mysafirit nuk jep lejen e resë.

Socketi i tunelit ka vendimin e vet për burimin

Address i WireGuard nën wg-quick cakton një adresë për ndërfaqen WireGuard; nuk është udhëzim për lidhje të jashtme UDP. Burimi i socketit të kriptuar ndjek tabelën e rrugëve, prandaj një rrugë politike ose një rrugë e dytë e parazgjedhur mund ta zhvendosë pa prekur adresën e ndërfaqes.OpenVPN: opsioni local dhe UDP multihome sillen njësoj: kanë të bëjnë me dëgjuesin dhe përgjigjet e tij, jo me burimin e internetit të çdo klienti të përcjellë.

Ruani rrugën e shtresës së poshtme që mban tunelin dhe konfirmoni që klienti ende merr përgjigje të vërtetuara nga rregullimi i pritur i hyrjes. Mos u mbështetni te rendi i listës së adresave si politikë e përhershme e zgjedhjes së burimit, sepse adresa e ardhshme e shtuar në NIC mund të ndryshojë cila fiton.

Çfarë të pranohet dhe në çfarë rendi

Pranoni tre rezultate veçmas. Së pari, një klient i jashtëm arrin hyrjen e synuar VPN. Së dyti, një kërkesë e re e lejuar nga ai klient VPN del përmes daljes së dokumentuar të internetit. Së treti, rrugët e padëshiruara të dëgjuesit dhe të përcjelljes mbeten të refuzuara. Regjistroni hartëzimet publik-në-privat dhe përgjegjësit e mysafirit dhe të resë për çdo vendim në të njëjtin vend.

Një tunel i suksesshëm provon vetëm pjesën e parë. Provoni daljen me një rrjedhë të re, sepse një lidhje e ruajtur në cache mund të vazhdojë të përdorë burimin e vjetër shumë kohë pas ndryshimit të rrugës.