SoftEther SecureNAT: DHCP in NAT sta dve odločitvi

SecureNAT je eno potrditveno polje, ki vklopi dve storitvi, in od tod izvira večina zmede okoli njega. Virtualni strežnik DHCP klientu dodeli naslov, masko, prehod in pogosto razreševalnik. Virtualni NAT posreduje pakete onkraj tega prehoda z uporabo lastnega omrežnega sklada gostitelja strežnika. Oba stojita drug ob drugem v konfiguraciji in odpovedujeta neodvisno: klient ima lahko brezhiben najem in nobene delujoče poti ali delujočo pot z nastavitvami, ki kažejo na napačen razreševalnik. Preverjajte ju kot dve odločitvi in diagnoza bo kratka.

Dve storitvi za enim potrditvenim poljem

Stran virtualnega DHCP odgovarja na konfiguracijsko vprašanje: katere nastavitve prejme ta klient znotraj tega virtualnega zvezdišča. Stran virtualnega NAT odgovarja na vprašanje posredovanja: ko klient pošlje paket na naslov zunaj zvezdišča, ali ga strežnik prevede in posreduje. Prvo je lokalno za zvezdišče in ne potrebuje omrežja zgoraj. Drugo je v celoti odvisno od gostitelja.

Virtualni vmesnik gostitelja spada k prvi odločitvi, ne k drugi. Njegov naslov, pogosto privzeto nekaj kot 192.168.30.1, je prehod, ki ga ponuja storitev DHCP. To ni javni naslov poslušanja strežnika, in zamenjava obeh ustvari pravila požarnega zidu in nastavitve klienta, usmerjene v stroj, ki v tem omrežju ne obstaja.

Odločitev 1: kdo zagotovi naslov

Če je virtualni DHCP vklopljen, naj bi klienti prejeli najem v naboru, ki ste ga nastavili, z virtualnim vmesnikom gostitelja kot prehodom in razreševalnikom, ki ste ga navedli. Preglejte najem in ne besedila stanja klienta, ker «povezano» opisuje tunel in ne dodelitve naslova:

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

Dva načina odpovedi velja poznati, preden začnete odpravljati napake v čem drugem. Klient z ostankom statičnega naslova iz prejšnje zasnove ga bo obdržal in najem prezrl, kar je videti, kot da DHCP noče odgovoriti. In drug vir DHCP v premostenem segmentu bo tekmoval za iste kliente, kar daje občasne naslove in čakalno vrsto podpore, ki problema ne more ponoviti.

Prekrivajoči se nabori spadajo sem. Če se nabor virtualnega DHCP prekriva z LAN podomrežjem gostitelja ali z naborom drugega zvezdišča, klient dobi naslov, ki se usmerja dvoumno, in vsak poznejši preizkus ni dokončen.

Odločitev 2: kdo posreduje onkraj virtualnega prehoda

Ob vklopljenem virtualnem NAT strežnik prevede odhodni promet iz zvezdišča in ga pošlje skozi usmerjevalno tabelo gostitelja. To pomeni, da je veriga posredovanja: klient do virtualnega prehoda, virtualni NAT do sklada gostitelja, sklad gostitelja do svoje privzete poti. Vsak člen lahko odpove, ne da bi se dotaknil drugih, in podpisi odpovedi se razlikujejo.

Drugo odločitev preizkusite z nečim, kar mora zapustiti zvezdišče, ne z nečim, kar je zanj lokalno. Ping virtualnega prehoda dokaže le prvi člen in nič več:

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

Če razreševanje imen deluje, povezave na javni naslov pa odpovedujejo, ste v verigi posredovanja in ne v DHCP. Če odpove oboje, najprej preverite razreševalnik, ker bo razreševalnik, poslan kot nedosegljiv notranji naslov, naredil delujočo pot videti popolnoma polomljeno.

Posredovanje SecureNAT izvaja proces strežnika, ne pot posredovanja v jedru, ki bi jo uporabili z mostom. To je priročno in počasneje od mostenja, pomeni pa tudi, da lastna pravila požarnega zidu in usmerjevalne odločitve gostitelja še vedno veljajo za prevedeni promet. Virtualni NAT ne obide politike gostitelja; uporablja jo.

Lastna pot gostitelja je tretja stvar

Vse zgoraj predpostavlja, da gostitelj strežnika lahko doseže cilj. Gostitelj brez delujoče poti navzgor, z omejevalno odhodno politiko ali z družino naslovov, ki je nima, bo odpovedal pri drugi odločitvi, ne glede na to, kako pravilna je konfiguracija zvezdišča. Preverite gostitelja posebej, zunaj tunela, preden njegovo odpoved pripišete SoftEtherju.

SecureNAT tudi ni dovoljenje za doseganje vsakega omrežja, povezanega s strežnikom. Prevaja in posreduje promet, ki pride do njega; odločanje, kaj gostitelj sme doseči, ostaja delo požarnega zidu in usmerjanja gostitelja, in zasnova, ki se pri dodeljevanju dostopa zanaša na tunel, je eno slabo pravilo oddaljena od dajanja preveč.

Družine naslovov si zaslužijo lastno preverjanje. Delujoč primer DHCP za IPv4 ne dokazuje, da je v vaši gradnji prisotna vsaka zmožnost IPv6, zato preberite priročnik za različico, ki jo dejansko poganjate, preden obljubite vedenje dvojnega sklada. Razdelek o SecureNAT v priročniku pokriva funkcije virtualnega NAT in DHCP za trenutno izdajo.

Preverite vsako odločitev z njenim lastnim testom

Prvo odločitev sprejmite s preverjanjem najema: naslov v naboru, prehod enak virtualnemu vmesniku gostitelja, razreševalnik tisti, ki ste ga nastavili. Drugo sprejmite z odhodno zahtevo s klienta in pogledom na tabelo NAT na strežniku, ker je naraščajoče število sej edini neposredni dokaz, da prevajanje poteka in ni le vklopljeno.

Nato zapišite razdelitev v oblikovalsko opombo: katera komponenta zagotavlja naslov, katera posreduje in skozi kateri vmesnik gostitelja promet izhaja. Ko bo ponovni zagon spremenil vedenje, vam bo ta opomba povedala, katero od treh pregledati, namesto da bi vse znova zagnali in upali, da se bo simptom premaknil.

Še ena odločitev sodi v zapis, tudi če je danes ne sprejmete: SecureNAT in lokalni most sta različni zasnovi za isto zvezdišče, zvezdišče, ki potrebuje oboje, pa je zvezdišče, ki potrebuje drug načrt. Odločite se zavestno, zapišite zakaj, in naslednji človek tega ne bo moral rekonstruirati vzvratno iz delujoče konfiguracije.