Кој сообраќај на апликации навистина го носи SSH префрлањето?

Школка, локално префрлање, SOCKS и режимот на тунелски уред нудат различни интерфејси. Именувајте го оној што вашата апликација може да го користи пред да го споредите со рутирана VPN.

Терминалот се поврзува, поканата се појавува и сите се согласуваат дека SSH-пристапот работи. Потоа клиентот на базата на податоци на преносниот сметач сѐ уште не може да стигне до приватниот домаќин, а се обвинува сесијата. Она што е изградено е школка, а тоа е еден од четирите сосема различни интерфејси што SSH може да ги понуди. Прво именувајте го интерфејсот, потоа проверете дали апликацијата навистина го користи. Редоследот е важен, зашто секој интерфејс пропаѓа на свој начин.

Именувајте го интерфејсот пред да споредите нешто

Прирачникот на OpenSSH клиент разликува четири механизми што лесно се мешаат. Школка или далечинска наредба се извршува на SSH домаќинот. Локалното префрлање отвора слушачки сокет на клиентот и го воспоставува следното поврзување од далечната страна. Далечинското префрлање го прави обратното, слушајќи на страната на серверот. Динамичкото префрлање изложува SOCKS крајна точка за програми што знаат да ја користат.

  • Школка: програмата работи на далечинскиот сметач, локално ништо не слуша.
  • Локално префрлање: вашиот преносен сметач има порта, далечинскиот домаќин го остварува излезното поврзување.
  • Далечинско префрлање: далечната страна има порта, сообраќајот се враќа кон вас.
  • Динамичко: SOCKS посредник на клиентот, го користат само апликации што го разбираат посредникот.

Ниту едно од овие не инсталира рута. Програма што ги игнорира поставките за посредник, или зборува UDP, или сама ги решава имињата, не е засегната од активна SSH сесија. Тоа не е грешка во SSH; тоа е опфатот на интерфејсот што го избравте.

Локалното, далечинското и динамичкото префрлање се разликуваат по тоа кој слуша

Разликата што решава повеќето случаи е кој го поседува слушачкиот сокет. Кај локалното префрлање клиентот слуша и далечниот крај го бира одредиштето, затоа адресата на одредиштето се решава од гледна точка на серверот. Кај далечинското префрлање серверот слуша и врската се пренесува назад кон вашата страна, и така изложувате локална услуга без директно да ја објавите.

ssh -N -L 5432:db.internal.example:5432 [email protected]
ssh -N -D 1080 [email protected]
ss -ltnp | grep -E '5432|1080'

Првата наредба ја врзува портата 5432 на преносниот сметач и ја префрла кон базата на податоци како што се гледа од бастионот. Втората создава SOCKS посредник на портата 1080. Третата наредба потврдува кои процеси навистина слушаат, и тоа е единствениот доказ дека префрлањето постои, а не дека тивко пропаднало поради судир на порти.

Динамичкото префрлање заслужува сопствено предупредување: го покрива само апликациите што го почитуваат SOCKS. Прелистувачот може да се насочи кон него, на алатката од командната линија може да ѝ се каже да го користи, но драјверот за база на податоци со сопствен стек за поврзување обично не може. Претпоставката дека секоја програма на сметачот сега го користи тунелот е најчестата грешка во целото ова подрачје.

Режимот на тунелски уред е единствениот вистински мрежен исклучок

OpenSSH поддржува и -w префрлање на тунелски уред, што пренесува интерфејс од точка до точка наместо TCP слушач. Тоа е вистински мрежен тунел и се конфигурира намерно, а не како несакан ефект од отворање школка.

sudo ssh -w 0:0 [email protected]
ip addr show tun0

Потребни се соодветните броеви на интерфејси достапни на двата краја, правилна конфигурација на серверот и доволно привилегии на клиентот за создавање на уредот. Потребен е и план за адресирање и рутирање, бидејќи голиот интерфејс не носи никаква политика за тоа кои одредишта треба да го користат.

Дури и тогаш тунелот завршува на далечинскиот домаќин. Каква и да е заштитата што ја дал SSH преносот, таа завршува таму, а понатамошното поврзување е одделен скок. VPN портата има ист облик на граница, затоа споредбата треба да биде за опфатот и завршувањето, а не за тоа која алатка е посилна. Гласното именување на таа граница ја решава и расправата за тоа дали тунелот «шифрира сѐ», бидејќи очигледно не шифрира.

Проверете дали вашата апликација го користи интерфејсот што го изградивте

Проверката е за секоја апликација, не за сесијата. Работечко префрлање докажува дека портата е врзана и далечната страна може да бира; тоа не докажува дека програмата што ви е важна се поврзала преку него.

curl -sS --socks5-hostname 127.0.0.1:1080 -o /dev/null -w '%{http_code}\n' https://app.internal.example/health
psql "host=127.0.0.1 port=5432 dbname=app sslmode=require" -c 'select 1'

Првата наредба испраќа барање преку SOCKS крајната точка со името на домаќинот решено оддалечено, а втората ја испробува префрлената порта на базата на податоци со TLS сѐ уште потребен. Извршете ги истите тестови со запрено префрлање за да потврдите дека пропаѓаат, бидејќи тест што поминува на двата начина никогаш не го користел тунелот.

Потоа споредете со рутирана VPN само во димензиите што се важни: кои одредишта се покриени, кои протоколи работат, каде завршува заштитата и кој треба да го одобри пристапот. Префрлањето за една услуга може да биде потесен и подобар одговор, додека VPN е вистинската форма кога многу апликации бараат истиот мрежен пат. Ниту едно не дава сѐ што е достапно од неговиот далечен крај.

Поврзани статии