Устройството ви стои зад NAT на оператора, може да отваря изходящи връзки и пуска SSH сървър, до който никой не може да стигне. Заявката, която пристига, обикновено звучи като "дайте му VPN", което е един от няколко отговора. Преди да го приемете, решете дали ви трябва един административен TCP порт, или маршрутизиран път до цяла подмрежа, защото това са различни проекти с различно излагане.

Обратният тунел отговаря добре на тясната версия. Устройството се свързва с вашия хъб, иска от хъба да слуша на loopback порт и препраща този порт обратно към собствената си SSH услуга. След това администраторите достигат слушателя през хъба, а не през публичния интернет.

Три условия, които решават избора

Запишете ги преди всяка конфигурация. Те са границата между ограничен административен вход и разширение на мрежата, а объркването им е начинът, по който тунел от пет реда се превръща в безстопанствена плоска мрежа.

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

Третият ред е този, за който хората спорят. Тунел към SSH порта на устройство не поставя съседите му в мрежата ви и не бива да се прави да изглежда, че го прави чрез верига от допълнителни препращания. Ако изискването наистина е LAN, кажете го и проектирайте него вместо това.

От страна на хъба: ограничен релей акаунт

Дайте на всяко устройство собствен релей акаунт с автентикация с публичен ключ и без интерактивна сесия. Match блок, ограничен до този акаунт, държи разрешението малко, а частният ключ остава на устройството, където му е мястото.

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 е интересният ред. Той отказва сесии на обвивка и подсистеми, като същевременно разрешава препращането, от което устройството се нуждае, така че откраднат ключ не може да се превърне в интерактивен вход. PermitListen фиксира адреса и порта на слушателя от страна на хъба, а GatewayPorts no го държи на loopback, вместо да го отваря към мрежата, в която се намира хъбът.

Тествайте ефективната конфигурация преди презареждане и дръжте втора сесия отворена, докато го правите. Match блок, който случайно се прилага за всички, или печатна грешка в име на опция, е класическият начин да се заключите извън машината, която укрепвате. Изхвърлете работещата конфигурация и прочетете опциите обратно, вместо да вярвате на файла, който току-що написахте. Отбележете, че поддръжката на опции се различава между версиите, така че приет ред в по-нов сървър може просто да бъде игнориран от по-стар.

От страна на устройството: препращане, което се проваля шумно

Устройството отваря връзката и заявява слушателя. Двата адреса в аргумента -R означават различни неща и четенето им отляво надясно е най-бързият начин да запомните кой кой е.

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

Лявата двойка е където хъбът трябва да слуша. Дясната двойка е това, към което устройството се свързва при пристигане на заявка, решено от собствената му страна. Разменянето им създава тунел, който се вдига чисто и препраща на грешното място, което е по-лошо от провал.

ExitOnForwardFailure=yes кара командата да излезе, когато заявеният слушател не може да бъде установен, така че цикълът на рестартиране ви казва истината, вместо да остави полуработеща сесия. Той не казва нищо за това дали локалната SSH услуга е здрава по-късно, затова го съчетайте с мениджър на процеси и от време на време истински тест на връзката.

Никога не заменяйте адреса за слушане на loopback с шаблон, за да избегнете допълнителен хоп. Тази единствена промяна е разликата между административен път и публично достъпен порт и обикновено се случва по време на отстраняване на грешки, а после остава. Ако колега не може да стигне до порта през хъба, поправете конфигурацията на скока, вместо да разширявате обвързването. Loopback е целият аргумент за сигурност на този дизайн.

Административен достъп през хъба

Администратор с обикновен акаунт на хъба може да прескочи през него до препратения порт. Релей акаунтът не се използва за това и точно това е смисълът да ги държите отделно.

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

Проверете ключа на хоста на устройството под избрания псевдоним, защото този ключ идентифицира устройството в края на веригата, а тунелът е само транспорт. Входът от край до край все още удостоверява двата края; тунел, който завършва на споделен хъб, не го прави доверен път сам по себе си.

Поемете жизнения цикъл

Стартирайте командата на устройството под мениджър на процеси с точно един активен екземпляр и политика за рестартиране, избрана съзнателно. Опциите за поддържане на връзката откриват мъртъв партньор; те не съживяват процес, който е излязъл.

След това напишете процедурата за извеждане от експлоатация. Всяко устройство получава свой слушател и свой ключ, така че извеждането означава отнемане на този акаунт и премахване на този ключ, а не ротация на обща за целия флот тайна.

Накрая, помнете какво ви дава loopback. Той ограничава мрежовото излагане и не прави нищо за други локални потребители на споделен хъб, така че собствената политика за достъп на хъба все още трябва да е правилна. Справка за sshd_config документира всяка от използваните по-горе опции и си заслужава да прочетете изцяло разделите за препращане, преди да разширите която и да е от тях.

Подобни статии