Домаћин наставља да одговара на 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-а је друга кука

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

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

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

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

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

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

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

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

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

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

Отворите нову овлашћену везу са јавне стране и потврдите да одговор излази кроз предвиђени интерфејс. Затим проверите да неповезани захтев који покрене контејнер још увек следи VPN.

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

Повезани чланци