NAT вырашае, які адрас крыніцы ваш VPN-сервер бачыць насамрэч

Вы ўяўляеце, што VPN-сервер чытае адрас вашага ноўтбука з пакета і запісвае яго ў журнал. Насамрэч ён чытае тое, што апошні скок NAT змясціў у знешні загаловак, а на тэлефоне, які працуе як кропка доступу, гэта часта адрас, які дзеляць сотні іншых абанентаў. Уласны адрас вашай машыны 192.168.x.x ніколі не перасякае інтэрнэт у гэтым загалоўку, а адрас тунэля выдае сервер пасля таго, як злучэнне ўжо ўсталяванае. Таму калі журнал сервера і ip addr на ноўтбуку разыходзяцца, ніводзін з іх не памыляецца; яны апісваюць розныя ўзроўні адной сесіі.

Тры адрасы, і толькі адзін з іх у журнале

Блытаніна ўзнікае з таго, што тры адрасы зводзяць у адзін. Кожны мае іншага ўладальніка, жыве ў іншым загалоўку і дасягае сервера іншым шляхам.

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

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

Чаму запісаны набор змяняецца, пакуль тунэль застаецца ўзнятым

Пераўтварэнне адрасоў — гэта табліца з таймерам, а не пастаянная прывязка. Хатні маршрутызатар трымае сваё UDP-супастаўленне некаторы час пасля апошняга пакета, шлюз аператара па сваім раскладзе паўторна выкарыстоўвае парты, а тэлефон, які пераходзіць з Wi-Fi на LTE, вяртаецца з цалкам іншай крыніцай. Стандартныя значэнні conntrack у Linux — карысны арыенцір: nf_conntrack_udp_timeout складае 30 секунд, а варыянт для патокавага рэжыму — 120, таму ціхі тунэль можа страціць супастаўленне задоўга да таго, як карыстальнік гэта заўважыць.

Тунэль выжывае таму, што пратакол аўтэнтыфікуе партнёра, а не адрас. WireGuard пасля рукапаціскання не мае стану, таму любы аўтэнтыфікаваны пакет абнаўляе захаваны канцавы пункт, і перапрывязка выпраўляецца на наступным пакеце; менавіта для гэтага існуе persistent-keepalive = 25 — каб трымаць супастаўленне цёплым у час прастою. --float у OpenVPN робіць тую ж працу, дазваляючы аўтэнтыфікаванаму кліенту працягнуць з новага адраса і порта. У зборках 2.4 і 2.5, дзе float адключаны па змаўчанні, перапрывязка скідвае сесію, і кліент падключаецца нанова.

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

Што сервер можа прыпісаць, а што не

Міф, які варта забіць, — гэта думка, што пераўтварэнне хавае вас ад аператара. Яно змяняе этыкетку, а не назіранне. Шлюз за NAT аператара бачыць прастору 100.64.0.0/10 або адзін публічны адрас, які дзеляць многія абаненты, і ўсё ж можа звязаць паток з суб'ектам сертыфіката, публічным ключом WireGuard, прызначаным адрасам тунэля, лічыльнікамі байтаў і часавым акном. Нішто з гэтага не патрабуе вашага адраса LAN.

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

Параўноўвайце абодва канцы замест здагадак

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

ss -uapn 'dport = :51820'
ip -4 route get 203.0.113.10
wg show wg0 endpoints

Затым прачытайце запіс пераўтварэння на маршрутызатары або шлюзе CGNAT і тое, што ўрэшце прыходзіць на сервер:

conntrack -L -p udp --dport 51820
tcpdump -ni eth0 udp port 51820

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

Дзе розніца ламае ўсё

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

Тая ж блытаніна ўзнікае і на баку сервера. Калі сам VPN-бокс знаходзіцца за NAT, патрэбны пракід порта і працаздольны шлях пераадрасацыі; кіраўніцтва strongSwan па пераадрасацыі апісвае гэты выпадак для IPsec. Сервер, дасяжны толькі па прыватным адрасе, ніколі не бачыць пераўтвораны набор, які падаюць яго кліенты, і гэта іншая праблема, чым пераўтварэнне кліентаў.

Прайдзіце гэтыя чатыры праверкі па парадку і спыніцеся на першай, якая не прайшла:

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

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