Пасля змены IP-адраса сервера правіла SNAT усё яшчэ называе стары

Сервер пераехаў на новы адрас, кліенты ўсё яшчэ падключаюцца, і нішто з таго, што яны адпраўляюць, не дасягае інтэрнэту. Гэтае раздзяленне і ёсць падказка: слухаючы сокет і перанакіраванне порта перажылі пераезд, таму тунель узнімаецца, а пераўтварэнне крыніцы, якое прымяняецца да перанакіраваных пакетаў усё яшчэ называе адрас, якім хост ужо не валодае. Адказы на гэтыя перапісаныя пакеты ідуць да машыны, якой больш няма.

Падключэнне і перанакіраванне адмаўляюць у розных месцах

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

Змена адраса ламае толькі другое рашэнне, і менавіта таму сімптом чытаецца як "падключана, але без інтэрнэту". Гэта таксама тлумачыць, чаму звычайныя праверкі на баку кліента выглядаюць здаровымі: рукапацісканне завяршаецца, кліент атрымлівае адрас, і ping на тунельны адрас сервера можа нават адказаць. Гадзіны марнуюцца на кліента праз няспраўнасць, якая жыве на іншым баку, таму табліца правілаў — першае месца, дзе варта глядзець.

Прачытайце правіла і яго лічыльнікі перад рэдагаваннем

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

sudo iptables -t nat -L POSTROUTING -n -v --line-numbers
ip -4 addr show

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

Калі лічыльнікі застылі на нулі, пакеты ніколі не дасягаюць гэтага правіла, і адрас тут не пры чым. Шукайце канкурэнтнае правіла раней у ланцугу — так бывае, калі хтосьці дадае замену замест таго, каб правіць арыгінал. Параўнайце нумары правілаў з вывадам, які вы запісалі хвіліну таму. Парадак — частка канфігурацыі, а не касметычная дэталь.

Замяніце крыніцу або перастаньце яе называць

Калі хост мае стабільны адрас, замяніце правіла на месцы, а не дадавайце яшчэ адно. Замена па нумары правіла захоўвае парадак, ад якога залежыць астатні ланцуг.

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 10.151.0.40

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

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -o eth0 -j MASQUERADE

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

Два спосабы зрабіць замену няправільна

Пераўтварэнне пула ў тунельны адрас сервера замест яго LAN-адраса адпраўляе адказы прама назад у тунель, дзе іх маршрутызуюць да кліента, які іх ніколі не прасіў. Злучэнне спыняецца так, што выглядае як пятля маршрутызацыі, бо ёю і з'яўляецца.

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

Калі тунель таксама нясе IPv6, паўтарыце ўвесь агляд на другім стэку. Маршрут па змаўчанні IPv6 без пераўтварэння і без маршрутызаванага прэфікса знікае так жа ціха, і гэта лёгка забыць, бо ўсё зверху выглядае аднолькава.

Уваходныя сэрвісы патрабуюць адваротнага пераўтварэння

Сэрвіс на кліенце VPN, які павінен быць дасяжным звонку, патрабуе пераўтварэння прызначэння, а не крыніцы: публічны порт перапісваецца на тунельны адрас кліента перад уваходам. Затым шлях перанакіравання патрабуе відавочнага правіла, якое дазваляе гэты трафік.

sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 10.9.8.2:8080

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