Публикуване на портове в Docker и VPN източници: две съвпадения, които пропускате

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

Митът: разрешете VPN сървъра и готово

Маршрутизиран VPN може да запази адреса на клиентския тунел чак до хоста с Docker. Шлюз, който извършва транслация на източника, може да замени този адрес със своя. И двата дизайна са законни и дават различни източници за едно и също действие на потребителя.

Тоест фразата IP на VPN сървъра описва предположение, а не наблюдение. Докато не знаете кой от двата дизайна е пред вас, правилото е догадка.

Източник: клиентски пул или транслационен шлюз

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

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

Порт: DNAT променя числото, което съпоставяте

При обикновено публикуване през мост на Linux с Docker iptables преобразуването на хост от 8443 към порт 443 на контейнера се извършва, преди филтърът за препращане да работи. Пакетът пристига при филтъра с порт на местоназначение 443. Правило, което съвпада с 8443 в този момент, никога не се задейства, въпреки че 8443 е това, което клиентът е въвел.

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

Решете кое число изразява намерението. Съпоставете порта на контейнера след DNAT, когато правилото защитава услугата вътре в контейнера. Съпоставете първоначалното местоназначение с опцията conntrack, когато правилото трябва да описва какво е поискал клиентът, и приемете допълнителната цена на съпоставяне и вниманието с реда на правилата, които идват с това.

Верига: DOCKER-USER, а не INPUT

Ръководството на Docker за iptables поставя потребителската политика за препращане във веригата DOCKER-USER, която се оценява преди собствените правила за препращане на Docker. Правило, копирано от услуга на хоста във веригата INPUT, филтрира трафик, адресиран до хоста, а не трафик, препращан към контейнер. Тази грешка дава правило, което изглежда правилно и няма ефект върху пътя на контейнера.

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

Проверете с нови връзки

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

Редът на веригите и поведението при преобразуване на порта зад тези проверки са описани в ръководството на Docker за iptables. Прочетете го, преди да копирате рецепта, и потвърдете кой бекенд използва инсталираният Docker, защото бекендът nftables интегрира политиката по различен начин.