Објавување 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. Прочитајте го пред да копирате рецепт и потврдете кој backend го користи инсталираниот Docker, бидејќи backend-от nftables ја интегрира политиката поинаку.