Два кліенты VPN, два публічныя адрасы: прывядзіце SNAT у адпаведнасць
SNAT па крыніцы можа выбраць публічны адрас, але толькі пакуль шлюз яшчэ адрознівае кліентаў. Праверце крыніцу, якая засталася, перш чым пісаць правіла.
Два кліенты VPN могуць выходзіць праз два розныя публічныя адрасы IPv4, і правіла, якое гэта робіць, карацейшае, чым чакаюць большасць людзей. Працуе гэта не дзякуючы сінтаксісу iptables, а дзякуючы стану пакета, калі ён дасягае ланцуга выхаду: адрас крыніцы там па-ранейшаму павінен дазваляць адрозніваць кліентаў. Калі папярэдні masquerade ужо зліў абодвух на адзін адрас, ніякае правіла для асобнага кліента не верне гэтае размежаванне. Спачатку вырашыце гэтае пытанне, потым пішыце пераклад.
Якая тоеснасць дажывае да шлюза
Правіла супастаўляецца з адрасам крыніцы пакета, а не з імем карыстальніка VPN і не з назвай, якую паказвае кліенцкая праграма. Усё, што пераўтварае пакет раней на шляху, вызначае, што ваша правіла яшчэ можа ўбачыць. Запусціце табліцу nat па парадку і знайдзіце пункт, дзе крыніца яшчэ застаецца асобнай для кожнага кліента.
iptables -t nat -S POSTROUTING
Чытайце гэты спіс зверху. Правіла masquerade бліжэй да верху перапісвае крыніцу для кожнага адпаведнага патоку, а запісы для асобных кліентаў, размешчаныя пасля яго, супадаюць з адрасам, якога ўжо не існуе. Калі два прылады LAN дзеляць адзін тунель і прыходзяць як адзін унутраны адрас, праект павінен змяніцца раней за міжсеткавы экран: трымайце іх дыяпазоны крыніц асобнымі або дайце кожнаму ўласны ўнутраны адрас.
Прывяжыце прызначэнне ўнутранага адраса да аўтэнтыфікаванага кліента. Перадача гэтага адраса іншай прыладзе перадае разам з ім і палітыку выхаду, а пераўтварэнне крыніцы само па сабе не з'яўляецца доказам асобы.
Пераўтварэнне не можа выдумаць адрас
Кожны публічны адрас павінен быць прызначаны або маршрутызаваны да гэтага пункта выхаду, а адказы павінны знайсці шлях назад да яго. Правіла, якое адпраўляе трафік з адраса, куды ніхто не маршрутызуе назад, адкідаецца на далёкім канцы або атрымлівае адказ хосту, які ніколі гэтага не прасіў. Асобнік хмарнага правайдэра звычайна пераўтварае свой публічны адрас у адрас прыватнага інтэрфейса перш чым пакет выйдзе, таму крыніца SNAT павінна быць адрасам, які правайдэр прыме, а не значэннем, якое паказвае кансоль. Чытайце мадэль адрасоў правайдэра і прытрымлівайцеся яе, замест таго каб капіяваць публічнае значэнне ў кожны пакет.
На практыцы гэта значыць праверыць маршрутызаваны прэфікс у кансолі правайдэра перад тым, як дакрануцца да міжсеткавага экрана, і выкарыстоўваць адрас прыватнага інтэрфейса як крыніцу пераўтварэння, калі адлюстраванне адно да аднаго. Адрасы ў прыкладах ніжэй узятыя з дыяпазонаў дакументацыі, таму першае, што трэба замяніць, — гэта сам тэкст адраса.
Уставце перад агульным masquerade
Пацвердзіце інтэрфейс выхаду і бягучы ланцуг, перш чым нешта дадаваць. Першае вызначае, якія пакеты можа супасціць правіла, а другое паказвае, што ўжо стаіць перад ім.
ip -4 route show default
iptables -t nat -L POSTROUTING -n -v --line-numbers
Першая каманда называе інтэрфейс, праз які пакет да інтэрнэту сапраўды выходзіць. Другая друкуе ланцуг з нумарамі радкоў. Запіс агульнага masquerade — гэта радок, вышэй якога трэба заставацца.
iptables -t nat -I POSTROUTING 1 -s 10.88.4.20/32 -o ens3 -j SNAT --to-source 198.51.100.77
iptables -t nat -I POSTROUTING 1 -s 10.88.4.21/32 -o ens3 -j SNAT --to-source 198.51.100.78
Два правілы вышэй супастаўляюцца з адным унутраным адрасам кожнае, абмяжоўваюць супастаўленне інтэрфейсам выхаду і задаюць крыніцу яўна. Устаўце, а не дапішыце: на пазіцыі 1 яны ацэньваюцца перад радком masquerade. Парадак паміж імі не мае значэння, бо іх крыніцы розныя. Замяніце ens3 на тое, што паведаміла каманда маршруту, і трымайце іншых менеджэраў міжсеткавага экрана далей ад тых жа перахапнікаў, бо два інструменты, якія пішуць адну табліцу, — гэта звычайная прычына, чаму правільнае правіла не мае эфекту.
Дакажыце крыніцу новым патокам
NAT са станам прывязвае пераўтварэнне, калі паток пачынаецца, і паўторна выкарыстоўвае яго для наступных пакетаў, таму сеанс, адкрыты да змены, захоўвае старую крыніцу пасля змены. Толькі новае ініцыяванае злучэнне даказвае правіла.
conntrack -L -s 10.88.4.20 -p tcp --dport 443
Прачытайце напрамак адказу ў гэтым запісе: яго прызначэнне — адрас, які выдалены канец бачыць як крыніцу. Параўнайце яго з публічным адрасам, які вы мелі на ўвазе, і разглядайце запіс са старым адрасам як доказ патоку, што пачаўся занадта рана, а не як зламанае правіла. Папрасіце кліента адкрыць новае злучэнне і паўтарыце запыт. Поўнае ачышчэнне табліцы адсочвання, каб прымусіць тэст, перапыняе кожны іншы сеанс на шлюзе.
Пераўтварэнне дагэтуль не выбірае маршрут, не прапускае паток праз фільтр і не публікуе ўваходную паслугу. Няправільны маршрут і адсутнае правіла дазволу працягваюць даваць збой пасля бездакорнага правіла SNAT. Праверце таксама IPv6 і любы другасны шлях выхаду, затым запішыце пары ўнутраны-да-публічнага ў дакументацыю міжсеткавага экрана, каб наступная змена пачыналася з адлюстравання, а не з тэксту правіла.