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 адресата.

Ако двете снимки се согласуваат за торката, а тунелот сепак откажува, преводот не е вашиот проблем; преминете на ракувањето и на табелата за рутирање внатре во тунелот.