eth0:0 — гэта метка, а не прылада: выпраўце супадзенне SNAT

Нулявы лічыльнік азначае, што правіла называе інтэрфейс, якога не можа існаваць. Прачытайце рэальную прыладу, выпраўце супадзенне -o, затым свядома выберыце перакладзены адрас.

Правіла 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, лічыльнік, які зрушыўся, і крыніцу, якую бачыў далёкі бок. Гэты запіс адкажа на наступную справаздачу без паўтору блытаніны з аліясам.

Падобныя артыкулы