SoftEther SecureNAT: Ang DHCP at NAT ay dalawang desisyon

Ang SecureNAT ay isang solong kahon ng tsek na nagbubukas ng dalawang serbisyo, at doon nagmumula ang karamihan ng pagkalito tungkol dito. Ang virtual na DHCP server ay nagbibigay sa kliyente ng address, mask, gateway at madalas isang resolver. Ang virtual na NAT ay nagpapadala ng mga packet lampas sa gateway na iyon gamit ang sariling network stack ng host ng server. Nakatayo sila nang magkatabi sa configuration at nabigo nang magkahiwalay: ang kliyente ay maaaring may perpektong lease at walang gumaganang daan, o gumaganang daan na may mga setting na tumuturo sa maling resolver. Suriin sila bilang dalawang desisyon, at ang diagnosis ay nagiging maikli.

Dalawang serbisyo sa likod ng isang kahon ng tsek

Ang panig ng virtual na DHCP ay sumasagot sa tanong ng configuration: anong mga setting ang natatanggap ng kliyenteng ito sa loob ng virtual na hub na ito. Ang panig ng virtual na NAT ay sumasagot sa tanong ng pagpapasa: kapag nagpadala ang kliyente ng packet sa address sa labas ng hub, isinasalin at ipinapasa ba ito ng server. Ang una ay lokal sa hub at hindi nangangailangan ng network sa itaas. Ang pangalawa ay lubos na nakadepende sa host.

Ang virtual na interface ng host ay kabilang sa unang desisyon, hindi sa pangalawa. Ang address nito, madalas isang bagay na tulad ng 192.168.30.1 bilang default, ay ang gateway na iniaalok ng serbisyong DHCP. Hindi ito ang pampublikong address sa pakikinig ng server, at ang pagkalito sa dalawa ay gumagawa ng mga patakaran ng firewall at mga setting ng kliyente na nakaturo sa isang makina na wala sa network na iyon.

Desisyon 1: sino ang nagbibigay ng address

Kung bukas ang virtual na DHCP, dapat makatanggap ang mga kliyente ng lease sa pool na iyong na-configure, na ang virtual na interface ng host ang gateway at ang resolver na ibinigay mo. Suriin ang lease at hindi ang teksto ng estado ng kliyente, dahil ang «konektado» ay naglalarawan ng tunnel at hindi ng pagtatalaga ng address:

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

May dalawang paraan ng pagkasira na dapat malaman bago mag-debug ng anupaman. Ang kliyenteng may natirang static na address mula sa dating disenyo ay pananatilihin ito at papansinin ang lease, na mukhang tumatanggi ang DHCP na sumagot. At ang pangalawang pinagmulan ng DHCP sa isang segment na may tulay ay makikipagkumpitensya sa parehong mga kliyente, na gumagawa ng pabagu-bagong address at pila ng suporta na hindi maaaring muling likhain ang problema.

Ang magkakapatong na pool ay kabilang din dito. Kung ang pool ng virtual na DHCP ay napatungan sa subnet ng LAN ng host o sa pool ng ibang hub, makakakuha ang kliyente ng address na nairuruta nang malabo, at bawat kasunod na pagsubok ay walang hatol.

Desisyon 2: sino ang nagpapasa lampas sa virtual na gateway

Kapag bukas ang virtual na NAT, isinasalin ng server ang papalabas na trapiko mula sa hub at ipinapadala ito sa pamamagitan ng routing table ng host. Ibig sabihin, ang kadena ng pagpapasa ay: kliyente patungo sa virtual na gateway, virtual na NAT patungo sa stack ng host, stack ng host patungo sa default na ruta nito. Bawat kawing ay maaaring mabigo nang hindi hinahawakan ang iba, at magkaiba ang mga palatandaan ng pagkasira.

Subukan ang pangalawang desisyon sa isang bagay na kailangang umalis sa hub, hindi sa isang bagay na lokal dito. Ang pag-ping sa virtual na gateway ay nagpapatunay lamang ng unang kawing at wala nang iba pa:

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

Kung gumagana ang resolusyon ng pangalan ngunit nabigo ang mga koneksyon sa pampublikong address, nasa kadena ng pagpapasa ka at hindi sa DHCP. Kung nabigo ang dalawa, suriin muna ang resolver, dahil ang resolver na itinulak bilang hindi maabot na panloob na address ay gagawing ganap na sira ang isang gumaganang daan.

Ang pagpapasa ng SecureNAT ay ipinapatupad ng proseso ng server, hindi ng daan ng pagpapasa sa kernel na gagamitin mo sa isang tulay. Maginhawa ito at mas mabagal kaysa sa pag-tulay, at nangangahulugan din ito na ang sariling mga patakaran ng firewall at mga desisyon sa routing ng host ay nalalapat pa rin sa naisaling trapiko. Hindi nilalabag ng virtual na NAT ang patakaran ng host; ginagamit nito iyon.

Ang sariling daan ng host ay ikatlong bagay

Ipinapalagay ng lahat ng nasa itaas na maaabot ng host ng server ang destinasyon. Ang host na walang gumaganang ruta pataas, may mahigpit na patakaran sa labas, o may pamilya ng address na wala siya ay mabibigo sa pangalawang desisyon, gaano man katumpak ang configuration ng hub. Suriin ang host nang hiwalay, sa labas ng tunnel, bago ituring na kasalanan ng SoftEther ang kabiguan nito.

Ang SecureNAT ay hindi rin isang pahintulot na maabot ang bawat network na nakakabit sa server. Isinasalin at ipinapasa nito ang trapikong umaabot dito; ang pagpapasya kung ano ang maaaring maabot ng host ay trabaho pa rin ng firewall at routing ng host, at ang disenyong umaasa sa tunnel upang magbigay ng access ay isang masamang patakaran lamang ang layo mula sa magbigay ng sobra.

Ang mga pamilya ng address ay karapat-dapat sa sariling pagsusuri. Ang gumaganang halimbawa ng DHCP sa IPv4 ay hindi nagpapatunay na bawat kakayahan ng IPv6 ay naroroon sa iyong build, kaya basahin ang manwal para sa bersyong aktwal mong pinapatakbo bago mangako ng pag-uugali ng dual-stack. Ang seksyon ng SecureNAT sa manwal ay sumasaklaw sa virtual na NAT at DHCP na mga function para sa kasalukuyang release.

Suriin ang bawat desisyon sa sarili nitong pagsubok

Tanggapin ang unang desisyon sa pagsusuri ng lease: address sa pool, gateway katumbas ng virtual na interface ng host, resolver ang na-configure mo. Tanggapin ang pangalawa sa papalabas na kahilingan mula sa kliyente at isang sulyap sa talahanayan ng NAT sa server, dahil ang tumataas na bilang ng session ang tanging direktang ebidensya na nangyayari ang pagsasalin at hindi lamang ito nakabukas.

Pagkatapos itala ang paghahati sa tala ng disenyo: aling bahagi ang nagbibigay ng address, aling bahagi ang nagpapasa, at aling interface ng host lumalabas ang trapiko. Kapag binago ng restart ang pag-uugali, sasabihin sa iyo ng talang iyon kung alin sa tatlo ang dapat suriin sa halip na i-restart ang lahat at umasa na lilipat ang sintomas.

May isa pang desisyong kabilang sa talaan, kahit hindi mo ito gawin ngayon: Ang SecureNAT at isang lokal na tulay ay magkaibang disenyo para sa parehong hub, at ang hub na nangangailangan ng dalawa ay hub na nangangailangan ng ibang plano. Pumili nang sinasadya, isulat kung bakit, at hindi na kailangang buuin ito nang paurong ng susunod na tao mula sa tumatakbong configuration.