eth0:0 е етикет, а не устройство: поправете съвпадението за SNAT

Правило за NAT, което трябваше да даде на един пул VPN клиенти собствен публичен адрес, стои на нула пакета, докато същият пул продължава да излиза под грешен източник. Правилото обикновено не греши за адреса; греши за интерфейса. -o eth0:0 сочи към устройство, което не съществува, защото eth0:0 е етикет, прикачен към адрес, а устройството на този адрес е eth0. Наблюдението на броячите е най-бързият начин да го потвърдите, а поправката е по-малка, отколкото разследването подсказва.

Проверете как ядрото нарича устройството

Прочетете двата изгледа поотделно, преди да променяте каквото и да е:

ip link show
ip address show dev eth0
ip route get 203.0.113.20

Списъкът на връзките показва интерфейси. Списъкът на адресите може да покаже втори адрес IPv4, носещ етикета: eth0:0, а устройството за този адрес все още е eth0. Ръководството за адреси на iproute2 третира етикета като име на адреса, а не като втора връзка, и точно на това разграничение се крепи целият проблем.

Историята обяснява объркването. Старият синтаксис ifconfig eth0:0 наистина изглеждаше като нов интерфейс и скриптове от онази епоха все още сочат към такъв. В съвременна система псевдонимът е етикет върху адрес и нищо по пътя на маршрутизацията или netfilter не го третира като отделна изходна точка.

Проверете с какво правилото действително е съвпаднало

Четете броячите заедно със списъка на правилата, а не по памет:

iptables -t nat -L POSTROUTING -v -n --line-numbers

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

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

Проверете маршрута, който избра устройството

Postrouting NAT се изпълнява, след като маршрутът вече е избрал изходен интерфейс, затова интерфейсът в правилото трябва да е този, който маршрутът е избрал. Попитайте ядрото директно чрез ip route get за представителен адрес на клиент и прочетете и устройството, и източника, който то съобщава.

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

Изберете преведения източник нарочно

След като устройството е правилно, адресът на източника е отделно решение. Това е илюстративен пул IPv4 и само примерен адрес:

iptables -t nat -A POSTROUTING -s 10.8.1.0/24 -o eth0 \
  -j SNAT --to-source 203.0.113.20

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

Смяната на адреса на източника не е същото като смяна на връзката нагоре. Когато истинското изискване е различен физически път, политиката за маршрутизация трябва първо да избере този път; след това SNAT пренаписва източника на устройството, което политиката е избрала. Добавянето на още етикети към eth0 не дава нито маршрута, нито разрешението.

Проверете с връзка, която току-що отворихте

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

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