SoftEther SecureNAT: DHCP dhe NAT janë dy vendime

SecureNAT është një kuti e vetme zgjedhjeje që ndez dy shërbime, dhe prej këtej vjen pjesa më e madhe e konfuzionit rreth tij. Një server DHCP virtual i jep klientit një adresë, maskë, portë dhe shpesh një zgjidhës. Një NAT virtual i përcjell paketat përtej asaj porte duke përdorur vetë stivën e rrjetit të hostit të serverit. Të dy qëndrojnë krah për krah në konfigurim dhe dështojnë në mënyrë të pavarur: klienti mund të ketë një qira të përsosur dhe asnjë rrugë funksionale, ose një rrugë funksionale me cilësime që tregojnë zgjidhësin e gabuar. Kontrollojini si dy vendime, dhe diagnoza bëhet e shkurtër.

Dy shërbime pas një kutie zgjedhjeje

Ana e DHCP virtual përgjigjet një pyetjeje konfigurimi: çfarë cilësimesh merr ky klient brenda këtij hub-i virtual. Ana e NAT virtual përgjigjet një pyetjeje përcjelljeje: kur klienti dërgon një paketë drejt një adrese jashtë hub-it, a e përkthen dhe e përcjell serveri. I pari është lokal për hub-in dhe nuk kërkon rrjet sipër. I dyti varet plotësisht nga hosti.

Ndërfaqja virtuale e hostit i përket vendimit të parë, jo të dytit. Adresa e saj, shpesh diçka si 192.168.30.1 si parazgjedhje, është porta që ofron shërbimi DHCP. Nuk është adresa publike e dëgjimit të serverit, dhe ngatërrimi i të dyjave prodhon rregulla muri të zjarrit dhe cilësime klienti të drejtuara nga një makinë që nuk ekziston në atë rrjet.

Vendimi 1: kush e furnizon adresën

Nëse DHCP virtual është i aktivizuar, klientët duhet të marrin një qira në grupin që keni konfiguruar, me ndërfaqen virtuale të hostit si portë dhe zgjidhësin që keni dhënë. Inspektoni qiranë dhe jo tekstin e statusit të klientit, sepse «i lidhur» përshkruan tunelin dhe jo caktimin e adresës:

vpncmd localhost /SERVER /CMD SecureNatStatusGet
vpncmd localhost /SERVER /CMD DhcpGet
ip -4 addr show
ip route

Dy mënyra dështimi vlen t'i njihni përpara se të korrigjoni çdo gjë tjetër. Një klient me një adresë statike të mbetur nga një dizajn i mëparshëm do ta mbajë atë dhe do të injorojë qiranë, gjë që duket sikur DHCP refuzon të përgjigjet. Dhe një burim i dytë DHCP në një segment të urëzuar do të konkurrojë për të njëjtët klientë, gjë që prodhon adresa të ndërprera dhe një radhë mbështetjeje që nuk mund ta riprodhojë problemin.

Grupet që mbivendosen gjithashtu hyjnë këtu. Nëse grupi i DHCP virtual mbivendoset me nënrrjetin LAN të hostit ose me grupin e një hub-i tjetër, klienti merr një adresë që rrugëtohet në mënyrë të paqartë, dhe çdo provë e mëvonshme mbetet pa përfundim.

Vendimi 2: kush përcjell përtej portës virtuale

Me NAT virtual të aktivizuar, trafiku dalës nga hub-i përkthehet nga serveri dhe dërgohet përmes tabelës së rrugëzimit të hostit. Kjo do të thotë se zinxhiri i përcjelljes është: klienti drejt portës virtuale, NAT virtual drejt stivës së hostit, stiva e hostit drejt rrugës së saj të parazgjedhur. Çdo hallkë mund të dështojë pa prekur të tjerat, dhe shenjat e dështimit ndryshojnë.

Provoni vendimin e dytë me diçka që duhet të largohet nga hub-i, jo me diçka lokale për të. Ping drejt portës virtuale provon vetëm hallkën e parë dhe asgjë më shumë:

vpncmd localhost /SERVER /CMD NatGet
vpncmd localhost /SERVER /CMD NatTable
dig +short example.com
ip route get 203.0.113.10

Nëse zgjidhja e emrave funksionon por lidhjet drejt një adrese publike dështojnë, ju jeni në zinxhirin e përcjelljes dhe jo në DHCP. Nëse të dyja dështojnë, kontrolloni së pari zgjidhësin, sepse një zgjidhës i shtyrë si adresë e brendshme e paarritshme do ta bëjë një rrugë funksionale të duket plotësisht e thyer.

Përcjelljen e SecureNAT e zbaton procesi i serverit, jo rruga e përcjelljes në kernel që do të përdornit me një urë. Kjo është e përshtatshme dhe më e ngadaltë se ura, dhe do të thotë gjithashtu se rregullat e murit të zjarrit dhe vendimet e rrugëzimit të hostit ende zbatohen për trafikun e përkthyer. NAT virtual nuk e anashkalon politikën e hostit; e përdor atë.

Rruga e vetë hostit është një gjë e tretë

Gjithçka më sipër supozon se hosti i serverit mund të arrijë destinacionin. Një host pa rrugë funksionale lart, me politikë dalëse kufizuese ose me një familje adresash që nuk e ka do të dështojë në vendimin e dytë, sado i saktë të jetë konfigurimi i hub-it. Kontrolloni hostin veçmas, jashtë tunelit, përpara se ta atribuoni dështimin e tij SoftEther.

SecureNAT gjithashtu nuk është autorizim për të arritur çdo rrjet të lidhur me serverin. Ai përkthen dhe përcjell trafikun që arrin deri në të; të vendasish se ku mund të arrijë hosti mbetet punë e murit të zjarrit dhe e rrugëzimit të hostit, dhe një dizajn që mbështetet te tuneli për të dhënë akses është një rregull i keq larg dhënies së tepërt.

Familjet e adresave meritojnë kontrollin e tyre. Një shembull DHCP IPv4 që funksionon nuk vërteton se çdo aftësi IPv6 është e pranishme në ndërtimin tuaj, prandaj lexoni manualin për versionin që ekzekutoni vërtet përpara se të premtoni sjellje me stivë të dyfishtë. Seksioni SecureNAT i manualit mbulon funksionet virtuale NAT dhe DHCP për versionin aktual.

Verifikoni çdo vendim me provën e vet

Pranoni vendimin e parë me një kontroll qiraje: adresa në grup, porta e barabartë me ndërfaqen virtuale të hostit, zgjidhësi ai që konfiguruat. Pranoni të dytin me një kërkesë dalëse nga klienti plus një vështrim në tabelën NAT në server, sepse numri në rritje i sesioneve është e vetmja provë e drejtpërdrejtë që përkthimi po ndodh dhe jo vetëm që është aktivizuar.

Pastaj shënoni ndarjen në shënimin e dizajnit: cili komponent furnizon adresën, cili komponent përcjell dhe nëpër cilën ndërfaqe hosti trafiku del. Kur një rinisje ndryshon sjelljen, ai shënim ju tregon se cilin nga të tre duhet të inspektoni në vend që të rinisni gjithçka dhe të shpresoni se simptoma do të zhvendoset.

Një vendim tjetër i përket regjistrit, edhe nëse nuk e merrni sot: SecureNAT dhe një urë lokale janë dizajne të ndryshme për të njëjtin hub, dhe një hub që ka nevojë për të dyja është një hub që ka nevojë për një plan tjetër. Zgjidhni me vetëdije, shkruani pse, dhe personi tjetër nuk do të duhet ta rikonstruktojë mbrapsht nga një konfigurim që funksionon.