Публикуване на портове в Docker срещу VPN: накъде отива отговорът

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

Хостът продължава да отговаря по SSH, след като VPN с пълен тунел се вдигне, а услуга, публикувана чрез Docker на същата машина, замлъква. Слушателят не е счупен: контейнерът работи, преобразуването на порта съществува и пакетът пристига. Контейнерът е здрав и заявката наистина го достига. Разликата е откъде започва отговорът, когато Linux избира маршрута си, и тази разлика решава кой от двата дизайна по-долу ви трябва.

Проследете кортежа през дестинационния NAT

Вземете хост на 192.0.2.10, публикуващ TCP 2222 към контейнер на 172.30.240.5:22. Заявка от 198.51.100.25 се преобразува, преди да достигне контейнера, и контейнерът отговаря като себе си.

WAN request:      198.51.100.25 -> 192.0.2.10:2222
after DNAT:       198.51.100.25 -> 172.30.240.5:22
container reply:  172.30.240.5:22 -> 198.51.100.25

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

Защо правило само за хоста го пропуска

Правило, което избира таблицата WAN само за пакети от 192.0.2.10 покрива собствените демони на хоста и напълно пропуска този препратен отговор. Адресът на източника в отговора е 172.30.240.5, а не хостът.

Свръхкорекцията е да насочите всичко от контейнера през WAN, което също освобождава несвързаните изходящи връзки на контейнера от VPN. Това е различна политика от поисканата и обикновено изненадва някого по-късно.

Съпоставянето след DNAT е друга точка за прихващане

Документацията на Docker за защитната стена отбелязва, че обикновената потребителска филтрация вижда дестинацията след DNAT, така че съпоставянето на публикувания порт 2222 в нормално правило не е същото като съпоставяне на порт 22 на контейнера. Ако оригиналният кортеж е важен, използвайте поддържания механизъм за оригинална дестинация, вместо да гадаете кой порт е видим.

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

Дизайн A: носете решението като състояние на връзката

Маркер на връзката може да пренесе решението за входящия трафик през преобразуването, но трябва да бъде върнат на пакета преди търсенето на маршрут, което има значение. Етапите са:

  1. Заделете поле за маркер и приоритет на правило, които не се сблъскват с Docker, VPN или друг собственик на политика.
  2. Идентифицирайте само предвидената нова WAN връзка в точка преди DNAT, където проследяването на връзки е налично.
  3. Запишете решението в маркера на връзката, без да насилвате самата оригинална заявка към таблицата WAN.
  4. В посоката на отговора възстановете само своите битове на маркера върху пакета преди маршрутизирането.
  5. Изберете пълна WAN таблица достатъчно рано, за да не може правило на VPN да спечели първо.

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

Дизайн B: терминирайте на хоста

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

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

Проверете промяната, не намерението

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

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

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