SoftEtherin paikallinen silta vai SecureNAT: kumpi kannattaa kytkeä

Avaa SoftEther Manager, ja ensimmäinen todellinen päätös hubista ei ole valintaruutu vaan topologiakysymys. Paikallinen silta liittää hubin fyysiseen sovittimeen ja antaa olemassa olevan segmentin tarjota osoitteet, kun taas SecureNAT antaa hubille oman virtuaalisen reitittimen, NAT:in ja DHCP:n. Niiden välillä valitseminen muuttaa sitä, mistä osoitteet tulevat ja mikä laite vastaa niistä. Molempien kytkeminen päälle ja toive, että yksi voittaa, on tapa, jolla toimiva laboratorio muuttuu tukiketjuksi.

Aloita hubista, jota todella muokkaat

Manager näyttää palvelinten ja hubien puun, ja oletushubin määrittäminen on helppoa, kun asiakkaat yhdistävät toiseen, eri nimiseen hubiin. Napsauta hubia, lue sen nimi ja varmista, että sen alla luetellut istunnot ovat ne asiakkaat, joita yrität palvella. Tämä yksi tarkistus estää suurimman osan siitä sekaannuksesta, joka myöhemmin laitetaan protokollan syyksi.

Päätä sitten, mitä asiakas tarvitsee kauempaa päästä. Jaettu Ethernet-käyttäytyminen lähetyksineen ja LAN-palveluineen viittaa siltaan, reititetty yksityinen pääsy pieneen osoitealueeseen viittaa SecureNATiin, ja internet-poistuma on reitityspäätös, jonka kumpikin järjestely voi kantaa huonosti.

Kirjoita vastaus muistiin ennen kuin napsautat mitään, sillä nämä kaksi asetusta eivät ole vaihdettavissa ja peruuttaminen kestää kauemmin kuin päättäminen. Kahden minuutin kirjoittaminen säästää tunnin uudelleenyhdistämistä.

Mitä paikallinen silta tekee osoitteille

Paikallinen silta yhdistää hubin fyysiseen sovittimeen, joten hubista tulee osa kyseistä Ethernet-segmenttiä. Asiakkaat saavat osoitteensa siltä, mikä jo palvelee segmenttiä, ja niiden yhdyskäytävä on segmentin reititin. Asiakkaan näkökulmasta se on liittynyt toimiston LANiin, kaikkine saavutettavuutensa ja kaikkine altistumisensa kanssa.

Se tarkoittaa myös, että silta tarvitsee todellisen sovittimen, jolla on oikea ajurituki, ja että järjestelmänvalvojalla on oltava valtuus laajentaa segmenttiä. VPN-kirjautuminen todistaa todennuksen, ei oikeutta sijoittaa isäntää tuotanto-VLANiin. Tarkista, että ajurin nimi vastaa aiottua sovitinta, sillä väärän portin sillaaminen kaataa segmentin nopeasti. Jos sovitinluettelo on tyhjä tai silta ilmoittaa virheestä, syy liittyy yleensä ajuriin tai oikeuksiin eikä kryptografiaan.

Lue siltataulukko komentoriviltä, kun graafinen puu on epäselvä. Tuloste nimeää sovittimen, mitä puu ei aina tee.

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

Tyhjä siltaluettelo yhdistettyjen istuntojen kanssa on hyödyllinen kuva: asiakkaat ovat virtuaalisen hubin sisällä eikä mikään vielä laajenna sitä segmentille.

Mitä SecureNAT lisää ja mitä se kätkee

SecureNAT antaa hubille virtuaalisen reitittimen, NAT-toiminnon ja DHCP-palvelun, kaikki SoftEther-prosessin sisällä. Asiakkaat saavat osoitteet virtuaalisesta DHCP-alueesta, virtuaalinen reititin vastaa oletusyhdyskäytävästä ja poistuva liikenne käännetään. Fyysinen sovitin ei ole mukana, minkä vuoksi se toimii isännässä, jossa on yksi verkkokortti eikä kytkinasetuksia.

Hinta on se, että virtuaaliset osoitteet kuuluvat hubille eivätkä mille muulle. Toimiston LANissa oleva kone ei voi reitittää asiakkaan SecureNAT-osoitteeseen ilman apua, ja kaikki lähdeosoitteita lokittava näkee SoftEther-isännän käännetyn osoitteen. Jos pääsykäytäntösi tai auditointijälkesi riippuu asiakkaan todellisesta osoitteesta, kyse on suunnittelumuutoksesta eikä yksityiskohdasta. Se ratkaisee myös, näkeekö lähdeosoitesääntö asiakasta koskaan.

Se on myös DHCP-palvelin. Sen ajaminen segmentissä, jossa sellainen jo on, tai saman segmentin sillaaminen tuottaa kaksi vastaajaa ja arvaamattomia vuokria. Käsikirja käsittelee nämä kaksi toimintoa erillisinä valintoina juuri tästä syystä.

Tarkista, mitä hub palvelee juuri nyt, ennen kuin otat mitään muuta käyttöön. Jokainen komento tulostaa nykyisen tilan eikä aiottua.

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

Toisen kytkeminen päälle toista rikkomatta

Valitse järjestely, ota se käyttöön ja jätä toinen pois. Hub, jossa on sekä silta että SecureNAT käytössä, on hub, jolla on kaksi mahdollista vastausta samaan kysymykseen, ja asiakas uskoo sitä, joka saapuu ensin. Kun siirryt toisesta toiseen, poista vanha toiminto käytöstä ja yhdistä asiakas uudelleen sen sijaan, että olettaisit uuden asetuksen vaikuttavan olemassa olevaan istuntoon.

Järjestä muutos niin, ettei asiakaspooli ole päällekkäinen LAN-alueen kanssa. Päällekkäiset aliverkot ovat toiseksi yleisin syy tunneliin, joka yhdistyy ja ei sitten tavoita mitään, ja ne ovat näkymättömiä, kunnes vertaat molempia osoitesuunnitelmia rinnakkain.

Yhdistä sitten asiakkaasta uudelleen ja lue, mitä se sai, sillä hubin näkemys istunnosta ei ole asiakkaan näkemys omasta verkostaan. Uudelleenyhdistäminen on ainoa luotettava tapa pakottaa tuore vuokra.

Tarkista yhdyskäytävä ja nimipalvelin asiakkaassa

Onnistunut todennus kertoo, että tunnistetiedot toimivat ja hub hyväksyi istunnon. Se ei kerro mitään siitä, tavoittaako asiakas mitään, sillä se riippuu osoitteesta, maskista, yhdyskäytävästä ja DNS-palvelimesta, jotka se sai. Lue nuo neljä arvoa asiakkaasta ennen kuin kosket palvelinasetukseen uudelleen.

Windowsissa sovittimen tiedot näyttävät vuokran ja nimipalvelimen, ja reititystaulukko näyttää, onko tunneli todella oletuspolku.

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

Linux-asiakkaassa samat tiedot tulevat osoite-, reitti- ja nimipalvelintiedostoista. Oletusreitti on arvo, joka ratkaisee, lähteekö liikenne ylipäätään tunnelin kautta. Jos yhdyskäytävä osoittaa toimiston reitittimeen, kun tunneli odottaa kantavansa liikennettä, topologia on sillattu nimellisesti ja rikki käytännössä. Korjaa ensin osoitelähde, testaa sovellus uudelleen ja harkitse vasta sitten toisen tilan muuttamista.