SoftEther lokal bro eller SecureNAT: hva du skal slå på

Åpne SoftEther Manager, og den første virkelige beslutningen om en hub er ikke en avkrysningsboks, det er et topologispørsmål. En lokal bro knytter huben til en fysisk adapter og lar det eksisterende segmentet levere adresseringen, mens SecureNAT gir huben sin egen virtuelle ruter, NAT og DHCP. Valget mellom dem endrer hvor adressene kommer fra og hvilken enhet som svarer for dem. Å slå på begge og håpe at én vinner er måten et fungerende laboratorium blir en støttetråd.

Begynn med huben du faktisk redigerer

Manager viser et tre av servere og huber, og det er lett å konfigurere standardhuben mens klientene kobler til en annen med et annet navn. Klikk på huben, les navnet og bekreft at sesjonene som er listet under den, er klientene du prøver å betjene. Den ene kontrollen hindrer det meste av forvirringen som senere får skylden for protokollen.

Bestem deretter hva klienten trenger fra den fjerne enden. Delt Ethernet-atferd med kringkasting og LAN-tjenester peker på en bro, rutet privat tilgang til et lite adresseområde peker på SecureNAT, og en internettutgang er en rutingsbeslutning som begge ordningene kan bære dårlig.

Skriv ned svaret før du klikker på noe, fordi de to innstillingene ikke er utskiftbare, og angre tar lengre tid enn beslutningen. To minutters skriving sparer en time med gjentilkobling.

Hva en lokal bro gjør med adresseringen

En lokal bro kobler huben til en fysisk adapter, slik at huben blir en del av det Ethernet-segmentet. Klientene får adresser fra det som allerede betjener segmentet, og gatewayen deres er segmentets ruter. Fra klientens synspunkt har den blitt med i kontorets LAN, med all tilgjengeligheten og all eksponeringen det innebærer.

Det betyr også at broen trenger en ekte adapter med riktig driverstøtte, og at administratoren må være autorisert til å utvide segmentet. En VPN-pålogging beviser autentisering, ikke retten til å plassere en vert på et produksjons-VLAN. Kontroller at driverens navn samsvarer med adapteren du har tenkt på, fordi å bro den feil porten tar et segment ned raskt. Hvis adapterlisten er tom eller broen rapporterer feil, er svaret vanligvis knyttet til driver eller rettigheter, ikke kryptografi.

Les brotabellen fra kommandolinjen når det grafiske treet er tvetydig. Utdataene navngir adapteren, noe treet ikke alltid gjør.

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

En tom broliste med tilkoblede sesjoner er et nyttig bilde: klientene er inne i den virtuelle huben, og ingenting utvider den til et segment ennå.

Hva SecureNAT legger til, og hva det skjuler

SecureNAT gir huben en virtuell ruter, en NAT-funksjon og en DHCP-tjeneste, alt inne i SoftEther-prosessen. Klientene får adresser fra det virtuelle DHCP-området, den virtuelle ruteren svarer for standardgatewayen, og trafikk som må ut oversettes. Ingen fysisk adapter er involvert, og derfor fungerer det på en vert med ett nettverkskort og uten svitsjkonfigurasjon.

Prisen er at de virtuelle adressene tilhører huben og ingenting annet. En maskin på kontorets LAN kan ikke rute til en klients SecureNAT-adresse uten hjelp, og alt som logger kildeadresser ser den oversatte adressen til SoftEther-verten. Hvis tilgangsreglene eller revisjonssporet ditt avhenger av klientens virkelige adresse, er det en designendring og ikke en detalj. Det avgjør også om en kildeadresseregel noen gang vil se klienten.

Det er også en DHCP-server. Å kjøre den på et segment som allerede har en, eller å bro det segmentet samtidig, gir to svarere og uforutsigbare leier. Håndboken behandler de to funksjonene som separate valg nettopp av denne grunnen.

Undersøk hva huben betjener akkurat nå, før du aktiverer noe annet. Hver kommando skriver ut gjeldende tilstand, ikke den tiltenkte.

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

Slå på én uten å ødelegge den andre

Velg ordningen, aktiver den, og la den andre være av. En hub med både bro og SecureNAT aktiv er en hub med to mulige svar på det samme spørsmålet, og klienten vil tro på det som kommer først. Når du migrerer fra den ene til den andre, deaktiver den gamle funksjonen og koble klienten til på nytt i stedet for å anta at den nye innstillingen virker på en eksisterende sesjon.

Ordne endringen slik at klientpoolen ikke overlapper LAN-området. Overlappende subnett er den nest vanligste årsaken til en tunnel som kobler til og deretter ikke når noe, og de er usynlige til du sammenligner begge adresseplanene side om side.

Koble deretter til på nytt fra klienten og les hva den fikk, fordi hubens syn på sesjonen ikke er klientens syn på sitt eget nettverk. En gjentilkobling er den eneste pålitelige måten å tvinge frem en frisk leie.

Kontroller gatewayen og resolveren på klienten

En vellykket autentisering forteller at påloggingsdetaljene virker og at huben godtok sesjonen. Den sier ingenting om hvorvidt klienten når noe, fordi det avhenger av adressen, masken, gatewayen og DNS-serveren den fikk. Les de fire verdiene på klienten før du rører en serverinnstilling igjen.

På Windows viser adapterdetaljene leien og resolveren, og rutetabellen viser om tunnelen faktisk er standardveien.

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

På en Linux-klient kommer de samme opplysningene fra filene for adresser, ruter og resolver. Standardruten er verdien som avgjør om trafikken i det hele tatt går ut gjennom tunnelen. Hvis gatewayen peker på kontorets ruter mens tunnelen forventer å bære trafikken, er topologien broet i navnet og brutt i praksis. Rett adressekilden først, test applikasjonen på nytt, og vurder først deretter å endre den andre modusen.