SoftEther loka ponto aŭ SecureNAT: kiun ŝalti

Malfermu SoftEther Manager, kaj la unua reala decido pri hubo ne estas markobutono, ĝi estas topologia demando. Loka ponto ligas tiun hubon al fizika adaptilo kaj lasas la ekzistantan segmenton provizi adresadon, dum SecureNAT donas al la hubo propran virtualan enkursigilon, NAT kaj DHCP. Elekti inter ili ŝanĝas, de kie la adresoj venas kaj kiu aparato respondas pri ili. Ŝalti ambaŭ kaj esperi, ke unu venkos, estas la maniero per kiu funkcianta laboratorio fariĝas subtena fadeno.

Komencu ĉe la hubo, kiun vi efektive redaktas

Manager montras arbon de serviloj kaj huboj, kaj facilas agordi la defaŭltan hubon dum klientoj konektiĝas al alia kun malsama nomo. Klaku la hubon, legu ĝian nomon, kaj konfirmu, ke la sesioj sube estas la klientoj, kiujn vi volas servi. Tiu sola kontrolo malhelpas la plej grandan parton de la konfuzo, kiun oni poste kulpigas la protokolon.

Poste decidu, kion la kliento bezonas de la malproksima flanko. Komunigita Ethernet-konduto kun dissendo kaj LAN-servoj montras al ponto, enkursigita privata aliro al malgranda adresa gamo montras al SecureNAT, kaj eliro al interreto estas enkursiga decido, kiun ambaŭ aranĝoj povas porti malbone.

Skribu la respondon antaŭ ol klaki ion ajn, ĉar la du agordoj ne estas interŝanĝeblaj kaj malfaro daŭras pli longe ol la decido. Du minutoj da skribado ŝparas unu horon da rekonektado.

Kion loka ponto faras al adresado

Loka ponto ligas la hubon al fizika adaptilo, do la hubo fariĝas parto de tiu Ethernet-segmento. Klientoj ricevas adresojn de tio, kio jam servas la segmenton, kaj ilia enirejo estas la enkursigilo de la segmento. El la vidpunkto de la kliento ĝi aliĝis al la oficeja LAN, kun la tuta atingeblo kaj la tuta elmetiĝo, kiun tio implicas.

Tio ankaŭ signifas, ke la ponto bezonas realan adaptilon kun taŭga pelila subteno, kaj ke la administranto devas esti rajtigita etendi tiun segmenton. VPN-ensaluto pruvas aŭtentikigon, ne la rajton meti gastiganton sur produktan VLAN. Kontrolu, ke la pelila nomo kongruas kun la celata adaptilo, ĉar ponti la malĝustan havenon faligas segmenton rapide. Se la adaptila listo estas malplena aŭ la ponto raportas malsukceson, la kaŭzo kutime rilatas al pelilo aŭ privilegioj, ne al kriptografio.

Legu la pontotabelon el la komandlinio, kiam la grafika arbo estas ambigua. La eligo nomas la adaptilon, kion la arbo ne ĉiam faras.

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

Malplena pontalisto kun konektitaj sesioj estas utila bildo: la klientoj estas ene de la virtuala hubo kaj ankoraŭ nenio etendas ĝin al segmento.

Kion SecureNAT aldonas kaj kion ĝi kaŝas

SecureNAT donas al la hubo virtualan enkursigilon, NAT-funkcion kaj DHCP-servon, ĉion ene de la procezo SoftEther. Klientoj ricevas adresojn el la virtuala DHCP-gamo, la virtuala enkursigilo respondas pri la defaŭlta enirejo, kaj trafiko, kiu devas eliri, estas tradukata. Neniu fizika adaptilo partoprenas, kaj tial ĝi funkcias sur gastiganto kun unu retkarto kaj sen ŝaltila agordo.

La kosto estas, ke la virtualaj adresoj apartenas al la hubo kaj al nenio alia. Maŝino en la oficeja LAN ne povas enkursigi al la SecureNAT-adreso de kliento sen helpo, kaj ĉio, kio registras fontadresojn, vidas la tradukitan adreson de la SoftEther-gastiganto. Se viaj alirreguloj aŭ via revizia postsigno dependas de la reala adreso de la kliento, tio estas ŝanĝo de dizajno, ne detalo. Ĝi ankaŭ decidas, ĉu fontadresa regulo iam vidos la klienton.

Ĝi ankaŭ estas DHCP-servilo. Funkciigi ĝin sur segmento, kiu jam havas unu, aŭ ponti tiun segmenton samtempe, produktas du respondantojn kaj neantaŭvideblajn luojn. La manlibro traktas la du funkciojn kiel apartajn elektojn ĝuste pro tio.

Ekzamenu, kion la hubo nuntempe servas, antaŭ ol ŝalti ion alian. Ĉiu komando presas la nunan staton, ne la celatan.

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

Ŝalti unu sen rompi la alian

Elektu la aranĝon, ŝaltu ĝin, kaj lasu la alian malŝaltita. Hubo kun ponto kaj kun SecureNAT ambaŭ aktivaj estas hubo kun du eblaj respondoj al la sama demando, kaj la kliento kredos tiun, kiu alvenas unue. Kiam vi migras de unu al la alia, malŝaltu la malnovan funkcion kaj rekonektu la klienton anstataŭ supozi, ke la nova agordo efikas sur ekzistantan sesion.

Ordigi la ŝanĝon tiel, ke la klienta baseno ne interkovru la LAN-gamon. Interkovrantaj subretoj estas la dua plej ofta kaŭzo de tunelo, kiu konektiĝas kaj poste atingas nenion, kaj ili estas nevideblaj ĝis vi komparos ambaŭ adresplanojn flanke unu apud la alia.

Poste rekonektu de la kliento kaj legu, kion ĝi ricevis, ĉar la vido de la hubo pri la sesio ne estas la vido de la kliento pri sia propra reto. Rekonekto estas la sola fidinda maniero devigi freŝan luon.

Kontrolu la enirejon kaj la solvilon ĉe la kliento

Sukcesa aŭtentikigo diras al vi, ke la akreditaĵoj funkcias kaj ke la hubo akceptis la sesion. Ĝi diras nenion pri tio, ĉu la kliento atingas ion, ĉar tio dependas de la adreso, masko, enirejo kaj DNS-servilo, kiujn ĝi ricevis. Legu tiujn kvar valorojn ĉe la kliento antaŭ ol vi denove tuŝos servilan agordon.

En Windows la adaptila detalo montras la luon kaj la solvilon, kaj la enkursiga tabelo montras, ĉu la tunelo efektive estas la defaŭlta vojo.

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

Ĉe Linux-kliento la samaj informoj venas el la dosieroj de adresoj, enkursigoj kaj solvilo. La defaŭlta enkursigo estas la valoro, kiu decidas, ĉu trafiko entute eliras tra la tunelo. Se la enirejo montras al la oficeja enkursigilo dum la tunelo atendas porti la trafikon, la topologio estas pontita laŭnome kaj rompita praktike. Riparu unue la adresfonton, poste retestu la aplikaĵon, kaj nur poste pripensu ŝanĝi la alian reĝimon.