Eininga di står bak ein leverandør-NAT, ho kan opne utgåande samband, og ho køyrer ein SSH-tenar som ingen kan nå. Førespurnaden som kjem, blir vanlegvis formulert som "gi henne ein VPN", som er eitt svar blant fleire. Før du godtek det, må du avgjere om du treng éin administrativ TCP-port eller ein ruta veg til eit heilt subnett, fordi det er ulike prosjekt med ulik eksponering.

Ein omvend tunnel svarar godt på den tronge versjonen. Eininga ringjer opp huben din, ber huben lytte på ein loopback-port og vidaresender den porten tilbake til si eiga SSH-teneste. Deretter når administratorar lyttaren gjennom huben, ikkje gjennom det opne internettet.

Tre vilkår som avgjer valet

Skriv dei ned før noka konfigurasjon. Dei er grensa mellom ein avgrensa administrasjonsinngang og ei nettverksutviding, og å blande dei er korleis ein tunnel på fem linjer blir eit eigarlaust flatt nettverk.

ConditionReverse tunnel fitsSomething else is needed
How many services must be reachable?One, or a small fixed set on loopbackAnything that needs many ports or dynamic discovery
Who connects, and how are they authenticated?Named administrators with their own hub accountsThird parties, or anything needing per-flow audit you do not control
Does the device's own LAN need to be reachable?NoYes, so a routed VPN or a managed platform is the honest answer

Den tredje rada er den folk diskuterer. Ein tunnel til SSH-porten til ei eining set ikkje naboane hennar på nettverket ditt, og det bør ikkje få det til å sjå slik ut gjennom ei kjede av vidare vidaresendingar. Viss kravet verkeleg er LAN-et, sei det og design det i staden.

Hub-sida: ein avgrensa relay-konto

Gi kvar eining sin eigen relay-konto med autentisering med open nøkkel og utan interaktiv økt. Match blokk avgrensa til den kontoen held løyvet lite, og den private nøkkelen blir verande på eininga der han høyrer heime.

Match User relay-dev-7
    AuthenticationMethods publickey
    PubkeyAuthentication yes
    AllowTcpForwarding remote
    PermitListen 127.0.0.1:21022
    GatewayPorts no
    MaxSessions 0
    PermitTTY no
    X11Forwarding no
    AllowAgentForwarding no

MaxSessions 0 er den interessante linja. Ho nektar shell- og undersystemøkter medan ho framleis tillèt vidaresendinga eininga treng, slik at ein stolen nøkkel ikkje kan gjerast om til ei interaktiv innlogging. PermitListen festar adressa og porten til lyttaren på hub-sida, og GatewayPorts no held han på loopback i staden for å opne han mot nettverket huben står på.

Test den effektive konfigurasjonen før du lastar på nytt, og hald ei andre økt open medan du gjer det. Match blokk som ved eit uhell gjeld for alle, eller ein skrivefeil i eit opsjonsnamn, er den klassiske måten å låse seg ute av boksen du herdar. Dumpe den køyrande konfigurasjonen og les opsjonane tilbake i staden for å stole på fila du nettopp skreiv. Ver merksam på at opsjonsstøtte varierer mellom bygg, slik at ei linje som blir godteken i ein nyare tenar, rett og slett kan bli ignorert av ein eldre.

Einingssida: vidaresending som feilar høgt

Eininga opnar sambandet og ber om lyttaren. Dei to adressene i argumentet -R tyder ulike ting, og å lese dei frå venstre mot høgre er den raskaste måten å hugse kven som er kven.

ssh -NT \
    -o ExitOnForwardFailure=yes \
    -o ServerAliveInterval=30 \
    -o ServerAliveCountMax=3 \
    -R 127.0.0.1:21022:127.0.0.1:22 \
    [email protected]

Det venstre paret er der huben skal lytte. Det høgre paret er det eininga koplar til når ein førespurnad kjem, løyst frå eininga si eiga side. Å byte dei gir ein tunnel som kjem reint opp og vidaresender til feil stad, noko som er verre enn ein feil.

ExitOnForwardFailure=yes får kommandoen til å avslutte når den førespurde lyttaren ikkje kan etablerast, slik at ein omstartssløyfe fortel deg sanninga i staden for å etterlate ei halvfungerande økt. Ho seier ingenting om den lokale SSH-tenesta er sunn seinare, så kople henne saman med ein prosesshandsamar og ein sporadisk ekte tilkoplingsstest.

Erstatt aldri loopback-lytteadressa med eit jokerteikn for å unngå eit ekstra hopp. Den eine endringa er skilnaden mellom ein administrasjonsveg og ein offentleg tilgjengeleg port, og ho skjer vanlegvis under feilsøking og blir deretter verande. Viss ein kollega ikkje når porten gjennom huben, reparer jump-konfigurasjonen i staden for å utvide bindinga. Loopback er heile tryggingsargumentet for dette designet.

Administratortilgang gjennom huben

Ein administrator med ein vanleg konto på huben kan hoppe gjennom han til den vidaresende porten. Relay-kontoen blir ikkje brukt til dette, og det er nettopp poenget med å halde dei åtskilde.

ssh -J [email protected] -o HostKeyAlias=device-7 \
    -p 21022 [email protected]

Stadfest vertsnøkkelen til eininga under aliaset du valde, fordi den nøkkelen identifiserer eininga i enden av kjeda, og tunnelen er berre transport. Innlogginga ende til ende autentiserer framleis båe endar; ein tunnel som endar på ein delt hub, gjer han ikkje i seg sjølv til ein betrodd veg.

Ta eigarskap til livssyklusen

Køyr einingskommandoen under ein prosesshandsamar med nøyaktig éin aktiv instans og ein omstartspolicy du har valt medvite. Keepalive-opsjonane oppdagar ein død motpart; dei vekkjer ikkje opp ein prosess som har avslutta.

Skriv deretter nedleggingsprosedyren. Kvar eining får sin eigen lyttar og sin eigen nøkkel, så avvikling tyder å tilbakekalle den kontoen og fjerne den nøkkelen, ikkje å rotere ein hemmelegheit heile flåten deler.

Til slutt, hugse kva loopback gir deg. Det avgrensar nettverkseksponering og gjer ingenting med andre lokale brukarar på ein delt hub, så tilgangspolicyen til huben sjølv må framleis vere riktig. sshd_config-referanse dokumenterer kvar av opsjonane som er brukte ovanfor, og det er verdt å lese vidaresendingsavsnitta i sin heilskap før du utvidar nokon av dei.

Relaterte artiklar