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.

Ако и двата записа съвпадат по набора, а тунелът пак не работи, преводът не е вашият проблем; преминете към ръкостискането и към таблицата за маршрутизация вътре в тунела.