Падвойны NAT і ваш VPN: кліент працуе, сервер не

Ваш маршрутызатар стаіць за іншым маршрутызатарам, адрас WAN прыватны, а VPN-кліент усё роўна падключаецца. Такая камбінацыя здзіўляе людзей, якія чакаюць, што падвойны NAT зламае тунелі, але менавіта зыходныя злучэнні пераклад апрацоўвае найлепш. Размяшчэнне VPN-сервера за тымі ж двума слаямі — гэта выпадак, які звычайна правальваецца. Намалюйце кірунак злучэння, перш чым нешта змяняць.

Спачатку намалюйце кірунак злучэння

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

curl -s https://ifconfig.me
ip -brief address
traceroute -n 1.1.1.1

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

Зыходны кірунак: кліент просіць, перакладчыкі супастаўляюць

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

Збоі, якія сапраўды ўзнікаюць, звычайна звязаныя з тайм-аўтамі і падтрымкай пратаколаў, а не з колькасцю маршрутызатараў. Тунель, які абрываецца пасля некалькіх хвілін цішыні, — гэта супастаўленне, якое сканчаецца, і keepalive — стандартны адказ. У IPsec ёсць стандартныя пашырэнні NAT-traversal, таму сцвярджэнне, што ён не можа прайсці праз пераклад, проста памылковае. Калі тунель зусім не ўстанаўліваецца, паглядзіце на канцавы пункт і ўліковыя даныя, перш чым вінаваціць тапалогію.

wg show
ping -c3 10.8.0.1

Спыніцеся, калі зыходны тунель працуе з адной сеткі і не працуе з другой. Гэта параўнанне пра сеткі, а не пра колькасць маршрутызатараў.

Уваходны кірунак: перанакіраванне ахоплівае толькі вашае абсталяванне

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

nc -vz 203.0.113.10 51820
ss -lunp 'sport = :51820'

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

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

Тэстуйце адну зменную за раз

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

journalctl -u wg-quick@wg0 -n 30 --no-pager
ip route get 10.20.30.40

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

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