Как локалното пренасочване на SSH пренася TCP сесия на OpenVPN

Тук се натрупват три транспортни слоя и всеки има собствено кадриране. Полезният товар на VPN пътува в TLS сесия, тази TLS сесия пътува в TCP връзка към loopback порт, а байтовете на тази връзка пътуват в SSH към релейен хост, който отваря истинската TCP връзка към слушателя на VPN. Нищо в подредбата не променя това, което OpenVPN удостоверява, и нищо в нея не прави UDP слушател достъпен през TCP. Четете останалото като описание на пътя на байтовете, а не като рецепта за заобикаляне на мрежов контрол.

Какво всъщност пренася локалното пренасочване

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

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

Стартирането на SSH сесията доказва само, че релеят е достъпен и удостоверен. То не казва нищо за това дали следващият слушател работи, дали защитна стена между релея и слушателя приема връзката или дали VPN ще приеме профила ви.

Насочете клиента към локалния слушател

Обявен пример: релеят може да достигне TCP слушател на gw.internal.example:443, а висок локален порт излага този път само на тази машина.

ssh -N -L 127.0.0.1:24011:gw.internal.example:443 [email protected]

Ръководството на OpenSSH описва локалното пренасочване като приемане на TCP връзки локално и отваряне на следващата връзка от отдалечената страна. Вържете слушателя към loopback, а не към всеки интерфейс, защото пренасочване, достъпно от мрежата, е отворен релей с вашето име. Свързването с всички интерфейси също излага порта на всеки друг локален акаунт на споделена машина.

След това превключете VPN клиента в TCP режим и го насочете към 127.0.0.1:24011. Ако профилът използва UDP, този дизайн не може да помогне: пренасочването носи поток от байтове и през него няма път за дейтаграми.

Дръжте двете удостоверявания разделени

SSH удостоверява релейния хост. OpenVPN все още удостоверява връстника на VPN и дестинацията на loopback не променя това изискване. Изключването на проверките на сертификата, защото сокетът вече сочи към localhost, е най-лошото съкращение в този дизайн. То превръща транспортна подредба в подредба на доверие и никой не е одобрил второто.

Пазете котвата на доверие в профила, проверката на ролята на сървъра и проверката на името непокътнати. Ако клиентът ви сравнява името на сървъра с адреса, който е набрал, loopback може да се нуждае от явна настройка на името вместо изключена проверка, а документацията на профила е мястото, където да потвърдите кое поле се сравнява.

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

Не изграждайте цикъл под тунела

След като VPN инсталира маршрути, SSH връзката, която го носи, все още се нуждае от път до релея, който не минава през тунела. Ако маршрутът по подразбиране се премести към VPN и релеят е достъпен само през същия тунел, транспортът се срутва и VPN отива с него. Отказът изглежда като прекъснат тунел, а не като грешка в маршрутизацията, затова се диагностицира погрешно.

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

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

Затворете слушателя, когато приключите

Спрете SSH сесията, когато тунелът вече не е нужен, и потвърдете, че локалният порт е освободен. Забравено пренасочване държи удостоверен път отворен на машина, която може да е споделена.

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