Omlate SSH foar ien apparaat: loopback-lústerder as rûte VPN?

Jo apparaat sit efter in NAT fan 'e operator, it kin útgeande ferbiningen iepenje, en it draait in SSH-tsjinner dy't nimmen berikke kin. It fersyk dat binnenkomt wurdt meastentiids formulearre as "jou it in VPN", wat ien antwurd is fan ferskate. Foardat jo it akseptearje, beslute oft jo ien administratyf TCP-poarte nedich hawwe of in rûte nei in hiel subnet, want dat binne ferskate projekten mei ferskillende bleatstelling.

In omlate tunnel antwurdet goed op 'e smelle ferzje. It apparaat skillet jo hub oan, freget de hub om op in loopback-poarte te lústerjen, en stjoert dy poarte werom nei syn eigen SSH-tsjinst. Dêrnei berikke behearders de lústerder fia de hub, net fia it iepenbiere ynternet.

Trije betingsten dy't de kar beslisse

Skriuw se op foar elke konfiguraasje. Se binne de grins tusken in beheinde behearynfier en in netwurkútwreiding, en se trochinoar helje is hoe't in tunnel fan fiif rigels in flak netwurk sûnder eigner wurdt.

De tredde rige is dejinge dêr't minsken oer diskutearje. In tunnel nei de SSH-poarte fan in apparaat set syn buorlju net op jo netwurk, en it moat net lykje as docht it dat fia in keatling fan fierdere trochstjoeringen. As de eask echt it LAN is, sis it en ûntwerp dat ynstee.

Hub-kant: in beheind relais-account

Jou elk apparaat syn eigen relais-account mei autentikaasje fia iepenbiere kaai en sûnder ynteraktive sesje. Match blok beheind ta dat account hâldt de tastean lyts, en de priveekaai bliuwt op it apparaat dêr't er heart.

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 is de nijsgjirrige rigel. It wegeret shell- en subsysteemsesjes wylst it de trochstjoering tastean dy't it apparaat nedich hat, sadat in stellen kaai net yn in ynteraktive oanmelding feroare wurde kin. PermitListen fêstiget it adres en de poarte fan 'e lústerder oan 'e hub-kant, en GatewayPorts no hâldt it op loopback ynstee fan it iepen te setten foar it netwurk dêr't de hub op sit.

Test de effektive konfiguraasje foar it werladen, en hâld in twadde sesje iepen wylst jo dat dogge. Match blok dat by ûngelok foar elkenien jildt, of in typflater yn in opsjenamme, is de klassike manier om josels bûten de masine te sluten dy't jo ferhârje. Dump de rinnende konfiguraasje en lês de opsjes werom ynstee fan it bestân te fertrouwen dat jo krekt skreaun hawwe. Tink derom dat opsje-stipe ferskilt tusken builds, sadat in akseptearre rigel yn in nijere tsjinner gewoan negearre wurde kin troch in âldere.

Apparaatkant: trochstjoering dy't lûd mislearret

It apparaat iepenet de ferbining en freget de lústerder. De twa adressen yn it -R argumint betsjutte ferskillende dingen, en se fan links nei rjochts lêze is de fluchste manier om te ûnthâlden hokker hokker is.

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

It lofterpear is wêr't de hub lústerje moat. It rjochterpear is wêr't it apparaat mei ferbynt as in fersyk binnenkomt, oplost fan 'e eigen kant fan it apparaat. Se omwikselje jout in tunnel dy't skjin omheech komt en nei it ferkearde plak trochstjoert, wat slimmer is as in mislearring.

ExitOnForwardFailure=yes lit it kommando ôfslute as de frege lústerder net fêstige wurde kin, sadat in werstart-lus jo de wierheid fertelt ynstee fan in healwurkjende sesje efter te litten. It seit neat oer oft de lokale SSH-tsjinst letter sûn is, dus keppelje it oan in prosesbehearder en in no en dan echte ferbiningstest.

Ferfang nea it loopback-lústeradres troch in wildcard om in ekstra hop te foarkommen. Dy iene feroaring is it ferskil tusken in behearspaad en in iepenbier berikbere poarte, en it bart meastentiids by it debuggen en bliuwt dan. As in kollega de poarte fia de hub net berikke kin, reparearje dan de jump-konfiguraasje ynstee fan de bining te ferbreedzjen. Loopback is it hiele feiligensargumint fan dit ûntwerp.

Beheardertagong fia de hub

In behearder mei in gewoan account op 'e hub kin der trochhinne springe nei de trochstjoerde poarte. It relais-account wurdt hjirfoar net brûkt, en dat is krekt it punt fan se skieden te hâlden.

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

Ferifiearje de hostkaai fan it apparaat ûnder it alias dat jo keazen hawwe, want dy kaai identifisearret it apparaat oan 'e ein fan 'e keatling en de tunnel is allinnich ferfier. De ein-oan-ein-oanmelding autentisearret noch hieltyd beide einen; in tunnel dy't op in dielde hub einiget makket it net fansels in fertroude rûte.

Nim it libbenssyklus yn eigendom

Rin it apparaatkommando ûnder in prosesbehearder mei krekt ien aktyf eksimplaar en in werstartbelied dat jo bewust keazen hawwe. De keepalive-opsjes detektearje in deade partner; se wekkerje gjin proses dat ôfsluten is.

Skriuw dan de ôftankproseduere. Elk apparaat krijt syn eigen lústerder en syn eigen kaai, dus ûntmantelje betsjut dat account ynlûke en dy kaai fuorthelje, net in geheim rotearje dat de hiele float dielt.

Tink úteinlik oan wat loopback jo jout. It beheint netwurkbleatstelling en docht neat oan oare lokale brûkers op in dielde hub, dus it tagongsbelied fan 'e hub sels moat noch hieltyd goed wêze. sshd_config-referinsje dokumintearret elk fan 'e hjirboppe brûkte opsjes, en it is de muoite wurdich de trochstjoeringsseksjes folslein te lêzen foardat jo ien fan har ferbreedzje.