NAT ang nagtatakda kung aling source address ang aktwal na nakikita ng iyong VPN server

Iniisip mo na binabasa ng VPN server ang address ng iyong laptop mula sa packet at isinusulat ito sa log. Ang binabasa nito ay ang inilagay ng huling NAT hop sa panlabas na header, at sa teleponong ginagamit bilang hotspot ito ay madalas na address na ibinabahagi sa daan-daang iba pang subscriber. Ang sariling address ng iyong makina 192.168.x.x ay hindi kailanman tumatawid sa internet sa header na iyon, at ang address ng tunnel ay ibinibigay ng server pagkatapos nang maitatag ang koneksyon. Kaya kapag ang log ng server at ip addr sa laptop ay hindi tugma, wala sa dalawa ang mali; inilalarawan nila ang magkaibang layer ng isang session.

Tatlong address, at isa lang ang nasa log

Nagmumula ang kalituhan sa pagpapaliit ng tatlong address sa isa. Bawat isa ay may ibang may-ari, nakatira sa ibang header at nakakarating sa server sa ibang landas.

Tanging gitnang hilera ang hindi alam sa sandali ng pagkonekta. Isinusulat ito ng server sa peer table, status file o flow log depende sa daemon: tinatawag ito ng WireGuard na endpoint, tinatag ito ng status file ng OpenVPN bilang Real Address, at iniuulat ito ng strongSwan bilang remote host ng IKE_SA. Ang halagang iyon ay nire-refresh tuwing may packet na dumarating mula sa ibang pinagmulan, kaya nagbabago ito nang walang nagre-restart ng kahit ano.

Ang ilalim na hilera ang madalas maling basahin ng mga tao bilang pag-aangkin ng pagkakakilanlan. Minamarkahan nito ang isang puwang sa configuration ng server, hindi isang tao, dahil pinili ito ng server mula sa sarili nitong pool. Dalawang user ang maaaring makatanggap ng parehong tunnel address sa magkaibang araw, at ang isa ay maaaring maghawak ng dalawa mula sa dalawang device.

Bakit nagbabago ang na-log na tuple habang nananatiling aktibo ang tunnel

Ang pagsasalin ng address ay isang table na may timer, hindi permanenteng pagkakabit. Ang router sa bahay ay nagtatago ng UDP mapping nito nang ilang sandali pagkatapos ng huling packet, ang gateway ng operator ay nagre-recycle ng port ayon sa sarili nitong iskedyul, at ang teleponong lumilipat mula Wi-Fi patungong LTE ay bumabalik na may ganap na ibang pinagmulan. Ang mga default ng conntrack sa Linux ay kapaki-pakinabang na batayan dito: nf_conntrack_udp_timeout ay 30 segundo at ang streaming variant ay 120, kaya ang tahimik na tunnel ay maaaring mawalan ng mapping bago pa man mapansin ng user.

Nabubuhay ang tunnel dahil ine-authenticate ng protocol ang peer, hindi ang address. Ang WireGuard ay walang state pagkatapos ng handshake, kaya ang anumang authenticated packet ay nag-a-update ng naka-store na endpoint at ang muling pagkakabit ay gumagaling sa susunod na packet; kaya may persistent-keepalive = 25, upang panatilihing mainit ang mapping habang idle. Ginagawa rin ito ng --float ng OpenVPN at hinahayaang magpatuloy ang authenticated client mula sa bagong address at port. Sa mga build 2.4 at 2.5 kung saan patay ang float bilang default, nire-reset ng muling pagkakabit ang session at muling kumokonekta ang client.

Naabot ito ng IPsec na may mas maraming gumagalaw na bahagi. Napapansin ng IKEv2 ang pagsasalin sa pamamagitan ng paghahambing ng source at destination hash sa NAT detection payloads, lumilipat sa UDP 4500 encapsulation, at sinusundan ang keepalive hanggang sa bagong tuple. Kapag naka-block ang keepalive, nananatiling buhay ang SA sa papel habang tahimik na humihinto ang trapiko sa isang direksyon.

Ano ang maiaatribusyon ng server, at ano ang hindi

Ang mitong dapat patayin ay ang pagtatago ng pagsasalin sa iyo mula sa operator. Binabago nito ang label, hindi ang obserbasyon. Ang gateway sa likod ng NAT ng operator ay nakikita ang espasyong 100.64.0.0/10 o isang pampublikong address na ibinabahagi ng maraming subscriber, at nagagawa pa ring iugnay ang flow sa paksa ng certificate, pampublikong susi ng WireGuard, itinalagang tunnel address, mga byte counter at isang time window. Wala sa mga ito ang nangangailangan ng iyong LAN address.

Ang mga limitasyon ay patungo rin sa kabilang direksyon. Ang ibinahaging address sa log ay tumutukoy sa gateway, hindi sa sambahayan; dalawang session mula sa parehong naisaling address sa magkaibang port ay magkaibang device; ang parehong address sa dalawang magkaibang araw ay maaaring dalawang walang kaugnayang subscriber kung na-recycle ang port. Ang server na nagtatala lamang ng peer key ay hindi maiaugnay ang isa sa customer nang walang account database, at ang server na nagtatala lamang ng address ay hindi matukoy ang pagkakaiba ng laptop sa telepono sa likod ng parehong router.

Ihambing ang dalawang dulo sa halip na manghula

Upang matiyak kung ano ang nangyari, kunin ang parehong koneksyon sa dalawang dulo sa parehong sandali at ihambing ang tuple, hindi ang address. Sa client, bago ang anumang pagsasalin:

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

Pagkatapos basahin ang translation entry sa router o sa CGNAT gateway, at ang tunay na dumarating sa server:

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

Tatlong pattern ang nagpapaliwanag sa karamihan ng hindi pagtutugma. Ang source port sa server ay iba sa lokal na port habang tugma ang destinasyon: ordinaryong port translation. Ang source address sa server ay kabilang sa ISP block na hindi sa iyo: hindi bababa sa isang karagdagang NAT layer. Humihinto ang packet pagkatapos ng panahon ng idle at nagpapatuloy sa bagong port: nag-expire ang mapping, hindi routing fault. Kung ang timestamp ay higit sa isang segundo o dalawa ang layo, inihahambing mo ang dalawang magkaibang pagtatangka.

Saan sumisira ang pagkakaiba

Ang mga pagkaantala na mukhang server fault ay karaniwang nagsisimula rito. Ang access rule na nakapin sa address ng bahay mo ay nabigo pagkatapos magbago ang lease ng ISP. Ang fail2ban rule na tumutugma sa naisaling address ay nagbabawal sa lahat ng subscriber sa likod ng gateway na iyon nang sabay. Ang site-to-site peer na may fixed na remote address ay humihinto sa pag-renew ng key pagkatapos magbago ang mobile link. Maayos ang protocol ng tunnel; ang palagay tungkol sa panlabas na tuple ay hindi.

Ang parehong kalituhan ay lumilitaw sa dulo ng server. Kung ang VPN box mismo ay nasa likod ng NAT, kailangan mo ng port forwarding at gumaganang forwarding path; sakop ng strongSwan forwarding guide ang kasong iyon para sa IPsec. Ang server na maaabot lamang sa pribadong address ay hindi kailanman nakikita ang naisaling tuple na ipinapakita ng mga client nito, at iba ito sa problemang isinasalin ang mga client.

Daanan ang apat na pagsusuring ito sa pagkakasunod-sunod at huminto sa unang nabigo:

• Kunin sa dalawang dulo nang sabay; kumpirmahin na tugma ang source port, destination port at timestamp.
• Basahin ang peer list ng server para sa address na hawak nito ngayon, hindi ang inaasahan mo.
• Suriin ang conntrack o NAT table para sa entry at sa natitirang buhay nito.
• Kumpirmahin na ang address ng tunnel interface sa client ay tugma sa itinalaga ng server, hindi sa LAN address.

Kung pareho ang sinasabi ng dalawang capture tungkol sa tuple at nabigo pa rin ang tunnel, hindi ang pagsasalin ang problema mo; magpatuloy sa handshake at sa routing table sa loob ng tunnel.