SoftEther SecureNAT: DHCP kaj NAT estas du decidoj

SecureNAT estas unu markobutono, kiu ŝaltas du servojn, kaj ĝuste tio estas la fonto de la plej multa konfuzo pri ĝi. Virtuala DHCP-servilo donas al la kliento adreson, maskon, enirejon kaj ofte solvilon. Virtuala NAT plusendas pakaĵojn preter tiu enirejo uzante la propran retostakon de la gastiga servilo. Ili staras unu apud la alia en la agordo kaj malsukcesas sendepende: kliento povas havi perfektan luon kaj nenian funkcian vojon, aŭ funkcian vojon kun agordoj direktitaj al la malĝusta solvilo. Kontrolu ilin kiel du decidojn, kaj la diagnozo fariĝos mallonga.

Du servoj malantaŭ unu markobutono

La virtuala DHCP-flanko respondas al agorda demando: kiujn agordojn ricevas ĉi tiu kliento ene de ĉi tiu virtuala hobo. La virtuala NAT-flanko respondas al plusenda demando: kiam kliento sendas pakaĵon al adreso ekster la hobo, ĉu la servilo tradukas kaj plusendas ĝin. La unua estas loka al la hobo kaj bezonas neniun supran reton. La dua tute dependas de la gastigo.

La virtuala gastiga interfaco apartenas al la unua decido, ne al la dua. Ĝia adreso, ofte io kiel 192.168.30.1 defaŭlte, estas la enirejo, kiun la DHCP-servo proponas. Ĝi ne estas la publika aŭskulta adreso de la servilo, kaj konfuzi la du kreas fajroŝirmilajn regulojn kaj klientajn agordojn celantajn maŝinon, kiu ne ekzistas en tiu reto.

Decido 1: kiu liveras la adreson

Se la virtuala DHCP estas ŝaltita, klientoj devus ricevi luon en la naĝejo, kiun vi agordis, kun la virtuala gastiga interfaco kiel enirejo kaj la solvilo, kiun vi provizis. Ekzamenu la luon anstataŭ la statustekston de la kliento, ĉar «konektita» priskribas la tunelon kaj ne la adresan asignon:

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

Du malsukcesaj reĝimoj indas esti konataj antaŭ ol vi sencimigos ion ajn alian. Kliento kun resta statika adreso el antaŭa dezajno konservos ĝin kaj ignoros la luon, kio aspektas kvazaŭ DHCP rifuzas respondi. Kaj dua DHCP-fonto sur pontigita segmento konkuros pri la samaj klientoj, kio produktas intermitajn adresojn kaj subtenan atendovicon, kiu ne povas reprodukti la problemon.

Sininterkovantaj naĝejoj ankaŭ apartenas ĉi tien. Se la virtuala DHCP-naĝejo interkovras la lokan subreton de la gastigo aŭ la naĝejon de alia hobo, la kliento ricevas adreson, kiu estas ambigue enkursigita, kaj ĉiu posta testado estas nekonkluda.

Decido 2: kiu plusendas preter la virtuala enirejo

Kun ŝaltita virtuala NAT, elira trafiko el la hobo estas tradukata de la servilo kaj sendata tra la enkursiga tabelo de la gastigo. Tio signifas, ke la plusenda ĉeno estas: kliento al virtuala enirejo, virtuala NAT al la stako de la gastigo, la stako de la gastigo al sia defaŭlta vojo. Ĉiu ligo povas malsukcesi sen tuŝi la aliajn, kaj la malsukcesaj signoprintoj malsamas.

Testu la duan decidon per io, kio devas forlasi la hobon, ne per io loka al ĝi. Pingingi la virtualan enirejon pruvas la unuan ligon kaj nenion pli:

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

Se nomtraduko funkcias sed konektoj al publika adreso malsukcesas, vi estas en la plusenda ĉeno kaj ne en DHCP. Se ambaŭ malsukcesas, kontrolu unue la solvilon, ĉar solvilo puŝita kiel neatingebla interna adreso igos funkcian vojon aspekti tute rompita.

La plusendadon de SecureNAT realigas la servila procezo, ne la kernplusenda vojo, kiun vi uzus kun ponto. Tio estas oportuna kaj pli malrapida ol pontigado, kaj ĝi ankaŭ signifas, ke la propraj fajroŝirmilaj reguloj kaj enkursigaj decidoj de la gastigo ankoraŭ validas por la tradukita trafiko. La virtuala NAT ne evitas la politikon de la gastigo; ĝi uzas ĝin.

La propra vojo de la gastigo estas tria afero

Ĉio supre supozas, ke la gastiga servilo povas atingi la celon. Gastigo sen funkcia supra enkursigo, kun restrikta elira politiko aŭ kun adresfamilio, kiun ĝi ne havas, malsukcesos ĉe la dua decido, kiom ajn ĝusta la hobagordo estas. Kontrolu la gastigon memstare, ekster la tunelo, antaŭ ol atribui ĝian malsukceson al SoftEther.

SecureNAT ankaŭ ne estas rajtigo atingi ĉiun reton ligitan al la servilo. Ĝi tradukas kaj plusendas trafikon, kiu atingas ĝin; decidi, kion la gastigo rajtas atingi, restas tasko de la fajroŝirmilo kaj enkursigo de la gastigo, kaj dezajno, kiu fidas la tunelon por doni aliron, estas unu malbona regulo for de doni tro multe.

Adresfamilioj meritas propran kontrolon. Funkcianta IPv4 DHCP-ekzemplo ne pruvas, ke ĉiu IPv6-kapablo ĉeestas en via konstruo, do legu la manlibron por la versio, kiun vi efektive funkciigas, antaŭ ol promesi duoblan stakan konduton. La SecureNAT-sekcio de la manlibro kovras la virtualajn NAT kaj DHCP funkciojn por la nuna eldono.

Kontrolu ĉiun decidon per ĝia propra testo

Akceptu la unuan decidon per lukontrolo: adreso en la naĝejo, enirejo egala al la virtuala gastiga interfaco, solvilo la agordita. Akceptu la duan per elira peto de la kliento plus rigardo al la NAT-tabelo sur la servilo, ĉar kreskanta sesiokvanto estas la sola rekta pruvo, ke tradukado okazas kaj ne nur ke ĝi estas ŝaltita.

Poste notu la dividon en la dezajna noto: kiu komponanto liveras la adreson, kiu komponanto plusendas, kaj tra kiu gastiga interfaco la trafiko eliras. Kiam restarto ŝanĝos la konduton, tiu noto diros al vi, kiun el la tri ekzamenu, anstataŭ restartigi ĉion kaj esperi, ke la simptomo moviĝos.

Ankoraŭ unu decido apartenas al la registro, eĉ se vi ne faras ĝin hodiaŭ: SecureNAT kaj loka ponto estas malsamaj dezajnoj por la sama hobo, kaj hobo, kiu bezonas ambaŭ, estas hobo, kiu bezonas alian planon. Elektu konscie, skribu kial, kaj la sekva persono ne devos retroinĝenieri ĝin el funkcianta agordo.