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 секунди, а streaming варијанта је 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 адресом.

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