Lokal na tulay ng SoftEther o SecureNAT: alin ang i-on

Buksan ang SoftEther Manager, at ang unang tunay na desisyon tungkol sa isang hub ay hindi isang kahon ng tsek, ito ay tanong ng topolohiya. Ang lokal na tulay ay nag-uugnay sa hub na iyon sa isang pisikal na adapter at hinahayaang ang umiiral na segment ang magbigay ng addressing, samantalang ang SecureNAT ay nagbibigay sa hub ng sarili nitong virtual na router, NAT at DHCP. Ang pagpili sa pagitan nila ay nagbabago kung saan nagmumula ang mga address at aling aparato ang sumasagot para sa kanila. Ang pag-on sa dalawa at umaasang mananalo ang isa ay ang paraan kung paano nagiging thread ng suporta ang isang gumaganang laboratoryo.

Magsimula sa hub na talagang ine-edit mo

Nagpapakita ang Manager ng puno ng mga server at hub, at madaling i-configure ang default na hub habang ang mga kliyente ay kumokonekta sa iba na may ibang pangalan. I-click ang hub, basahin ang pangalan nito, at tiyakin na ang mga session na nakalista sa ilalim nito ay ang mga kliyenteng sinusubukan mong servisuhan. Ang isang pagsusuring iyon ay pumipigil sa karamihan ng kalituhang ibinabaling sa protocol sa kalaunan.

Pagkatapos ay magpasya kung ano ang kailangan ng kliyente mula sa malayong dulo. Ang ibinahaging pag-uugali ng Ethernet na may broadcast at mga serbisyo ng LAN ay tumuturo sa isang tulay, ang niruruta na pribadong pag-access sa maliit na saklaw ng address ay tumuturo sa SecureNAT, at ang labasan sa internet ay desisyon sa rutang maaaring madaling dalhin ng alinman sa dalawang kaayusan.

Isulat ang sagot bago ka mag-click ng kahit ano, dahil ang dalawang setting ay hindi mapagpapalit at ang pag-undo ay mas matagal kaysa sa pagpapasya. Ang dalawang minutong pagsulat ay nakakatipid ng isang oras na muling pagkonekta.

Ano ang ginagawa ng lokal na tulay sa addressing

Iniuugnay ng lokal na tulay ang hub sa isang pisikal na adapter, kaya ang hub ay nagiging bahagi ng segment ng Ethernet na iyon. Ang mga kliyente ay tumatanggap ng address mula sa kung ano ang naglilingkod na sa segment, at ang kanilang gateway ay ang router ng segment. Sa pananaw ng kliyente, sumali siya sa LAN ng opisina, kasama ang lahat ng maabot at lahat ng pagkakalantad na dulot nito.

Nangangahulugan din ito na ang tulay ay nangangailangan ng tunay na adapter na may tamang suporta ng driver at ang administrador ay dapat may awtoridad na palawakin ang segment na iyon. Ang pag-login sa VPN ay nagpapatunay ng authentication, hindi ng karapatang maglagay ng host sa production VLAN. Tiyakin na ang pangalan ng driver ay tumutugma sa adapter na nilalayon mo, dahil ang pagtulay sa maling port ay mabilis na nagpapabagsak ng segment. Kung walang laman ang listahan ng adapter o nag-uulat ng pagkabigo ang tulay, ang sagot ay karaniwang nauugnay sa driver o mga pribilehiyo, hindi sa cryptography.

Basahin ang talahanayan ng tulay mula sa command line kapag malabo ang graphical na puno. Pinapangalanan ng output ang adapter, na hindi laging ginagawa ng puno.

vpncmd /SERVER localhost /HUB VPN /CMD BridgeList
vpncmd /SERVER localhost /HUB VPN /CMD SessionList

Ang walang laman na listahan ng tulay na may konektadong session ay kapaki-pakinabang na larawan: ang mga kliyente ay nasa loob ng virtual na hub at wala pang nagpapalawak nito sa isang segment.

Ano ang idinadagdag ng SecureNAT at ano ang itinatago nito

Binibigyan ng SecureNAT ang hub ng virtual na router, function ng NAT at serbisyo ng DHCP, lahat sa loob ng proseso ng SoftEther. Ang mga kliyente ay nakakakuha ng address mula sa virtual na saklaw ng DHCP, ang virtual na router ay sumasagot para sa default na gateway, at ang trapikong kailangang lumabas ay isinasalin. Walang pisikal na adapter ang kasangkot, kaya gumagana ito sa host na may isang NIC at walang configuration ng switch.

Ang halaga ay pag-aari ng hub ang mga virtual na address at wala nang iba. Ang isang makina sa LAN ng opisina ay hindi makakapagruta patungo sa SecureNAT na address ng isang kliyente nang walang tulong, at lahat ng nagtatala ng source address ay nakikita ang isinaling address ng host ng SoftEther. Kung ang iyong mga patakaran sa pag-access o trail ng audit ay nakadepende sa tunay na address ng kliyente, iyon ay pagbabago sa disenyo at hindi detalye. Ito rin ang nagpapasya kung makikita kailanman ng patakaran sa source address ang kliyente.

Ito rin ay isang DHCP server. Ang pagpapatakbo nito sa isang segment na mayroon na, o ang pagtulay sa segment na iyon nang sabay, ay lumilikha ng dalawang sumasagot at hindi mahuhulaang lease. Itinuturing ng manual ang dalawang function bilang magkahiwalay na pagpipilian dahil na rin dito.

Suriin kung ano ang sinisilbihan ng hub ngayon bago mo i-enable ang anupaman. Ang bawat command ay nagpi-print ng kasalukuyang estado, hindi ang nilalayon.

vpncmd /SERVER localhost /HUB VPN /CMD SecureNatStatusGet
vpncmd /SERVER localhost /HUB VPN /CMD NatGet
vpncmd /SERVER localhost /HUB VPN /CMD DhcpGet

I-on ang isa nang hindi sinisira ang isa

Piliin ang kaayusan, i-enable ito, at hayaang nakapatay ang isa. Ang hub na may tulay at may SecureNAT na parehong aktibo ay hub na may dalawang posibleng sagot sa parehong tanong, at ang kliyente ay maniniwala sa unang dating. Kapag lumipat ka mula sa isa patungo sa isa, i-disable ang lumang function at kumonekta muli ang kliyente sa halip na ipagpalagay na ang bagong setting ay gumagana sa umiiral na session.

Isaayos ang pagbabago upang ang pool ng kliyente ay hindi mag-overlap sa saklaw ng LAN. Ang mga magkakapatong na subnet ang pangalawang pinakakaraniwang dahilan ng tunnel na kumokonekta at pagkatapos ay walang naaabot, at hindi sila nakikita hanggang ihambing mo ang dalawang plano ng address nang magkatabi.

Pagkatapos ay kumonekta muli mula sa kliyente at basahin kung ano ang natanggap nito, dahil ang pananaw ng hub sa session ay hindi ang pananaw ng kliyente sa sarili nitong network. Ang muling pagkonekta ay ang tanging maaasahang paraan upang pilitin ang bagong lease.

Tiyakin ang gateway at ang resolver sa kliyente

Sinasabi ng matagumpay na authentication na gumagana ang mga kredensyal at tinanggap ng hub ang session. Wala itong sinasabi tungkol sa kung may naaabot ang kliyente, dahil nakadepende iyon sa address, mask, gateway at DNS server na natanggap niya. Basahin ang apat na halagang iyon sa kliyente bago mo muling hawakan ang setting ng server.

Sa Windows ang detalye ng adapter ay nagpapakita ng lease at ng resolver, at ang talahanayan ng ruta ay nagpapakita kung ang tunnel ay talagang default na landas.

ipconfig /all
route print -4
nslookup intranet.corp.internal

Sa kliyenteng Linux ang parehong impormasyon ay nagmumula sa mga file ng address, ruta at resolver. Ang default na ruta ang halagang nagpapasya kung ang trapiko ay lumalabas sa tunnel. Kung ang gateway ay tumuturo sa router ng opisina habang ang tunnel ay umaasang magdadala ng trapiko, ang topolohiya ay natulay sa pangalan at sira sa praktika. Ayusin muna ang pinagmulan ng address, pagkatapos ay subukan muli ang application, at pagkatapos lamang isaalang-alang ang pagbabago ng kabilang mode.