Објавување Docker порти наспроти VPN: каде оди одговорот

Објавен контејнер одговара од сопствената адреса пред обратен NAT. Два дизајна можат да го задржат тој одговор на јавниот пат, со различни трошоци.

Домаќинот продолжува да одговара на SSH откако ќе се крене VPN со целосен тунел, а услугата објавена преку Docker на истиот компјутер замолчува. Со слушателот сè е во ред: контејнерот работи, мапирањето на портата постои и пакетот пристигнува. Контејнерот е здрав и барањето навистина го достигнува. Разликата е од каде почнува одговорот кога Linux ја избира својата рута, и таа разлика одлучува кој од двата дизајна подолу ви треба.

Следете ја tuple низ 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

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

Зошто правило само за домаќинот го пропушта

Правило што ја избира WAN табелата само за пакети од 192.0.2.10 ги покрива сопствените демони на домаќинот и целосно го пропушта овој проследен одговор. Изворната адреса на одговорот е 172.30.240.5, а не домаќинот.

Претераната корекција е сè од контејнерот да се рутира преку WAN, што исто така ги иззема неврзаните излезни врски на контејнерот од VPN. Тоа е друга политика од побараната и обично некого изненадува подоцна.

Совпаѓањето по DNAT е друг hook

Документацијата на Docker за firewall-ови забележува дека обичното корисничко филтрирање ја гледа дестинацијата по DNAT, па совпаѓањето на објавената порта 2222 во нормално правило не е исто како совпаѓање на портата 22 на контејнерот. Ако оригиналната tuple е важна, користете го поддржаниот механизам за оригинална дестинација наместо да погодувате која порта е видлива.

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

Дизајн A: да се носи одлуката како состојба на врска

Ознаката на врската може да ја пренесе одлуката за влез низ преводот, но мора да се врати на пакетот пред важното пребарување на рута. Фазите се:

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

Таа табела ги бара вистинските поврзани рути и портата. Ѝ треба и дефинирано однесување кога рутата недостасува. Тихото пропаѓање во тунелот е најлошиот исход, бидејќи конфигурацијата сè уште изгледа како да работи. Наместо тоа, откажете затворено и запишете го тоа.

Дизајн B: завршете на домаќинот

Намерно конфигуриран фронтенд на страната на домаќинот, како TCP прокси или обратен прокси пред контејнерот, го задржува одговорот да потекнува од адресата на домаќинот. Тогаш правилата напишани за домаќинот се однесуваат како што се очекува, а контејнерот останува на својата приватна мрежа.

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

Проверете ја промената, не намерата

Отворете нова овластена врска од јавната страна и потврдете дека одговорот излегува низ предвидениот интерфејс. Потоа проверете дали неврзано барање што го започнува контејнерот сè уште го следи VPN.

Не ја празнете табелата со врски на машината за да тестирате едно правило: постојните записи го задржуваат претходното мапирање, а празнењето крши сè друго на домаќинот. Објавувањето порта дефинира достапност. Тоа не го дефинира патот на одговорот. Запишете го избраниот дизајн со имињата на неговите табели, за да не мора следниот човек повторно да го открива за време на инцидент.

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