NAT huamua anwani gani ya chanzo seva yako ya VPN inaona kwa kweli

Unafikiri seva ya VPN inasoma anwani ya kompyuta yako mpakato kutoka kwenye pakiti na kuiandika kwenye kumbukumbu. Inachosoma ni kile hopu ya mwisho ya NAT iliyoweka kwenye kichwa cha nje, na kwenye simu inayotumika kama hotspot mara nyingi ni anwani inayoshirikiwa na mamia ya wateja wengine. Anwani ya mashine yako mwenyewe 192.168.x.x haivuki kamwe intaneti katika kichwa hicho, na anwani ya handaki hutolewa na seva baada ya muunganisho kuwa tayari. Kwa hiyo anwani ya kumbukumbu ya seva na ip addr kwenye kompyuta mpakato zisipolingana, hakuna hata moja iliyo makosa; zinaelezea tabaka tofauti za kikao kimoja.

Anwani tatu, na moja tu iko kwenye kumbukumbu

Mkanganyiko unatokana na kuunganisha anwani tatu kuwa moja. Kila moja ina mmiliki tofauti, inaishi katika kichwa tofauti na kufikia seva kwa njia tofauti.

Mstari wa kati pekee haujulikani wakati wa kuunganisha. Seva huiandika kwenye jedwali la wenza wake, faili ya hali au kumbukumbu ya mtiririko kulingana na daemon: WireGuard huiita kituo cha mwisho, faili ya hali ya OpenVPN huiweka alama kama Real Address, na strongSwan huiripoti kama mwenyeji wa mbali wa IKE_SA. Thamani hiyo huisasishwa kila pakiti inapokuja kutoka chanzo kingine, kwa hiyo hubadilika bila mtu yeyote kuanzisha upya kitu chochote.

Mstari wa chini ni kile ambacho watu husoma kimakosa kama madai ya utambulisho. Unaonyesha nafasi katika usanidi wa seva, si mtu, kwa sababu seva iliuchagua kutoka dimbwi lake mwenyewe. Watumiaji wawili wanaweza kupata anwani sawa ya handaki siku tofauti, na mmoja anaweza kuwa na mbili kutoka vifaa viwili.

Kwa nini tuple iliyorekodiwa hubadilika wakati handaki linabaki hewani

Tafsiri ya anwani ni jedwali lenye kipima muda, si kifungo cha kudumu. Ruta ya nyumbani huweka ramani yake ya UDP kwa muda baada ya pakiti ya mwisho, lango la mtoa huduma hurejea bandari kwa ratiba yake mwenyewe, na simu inayohama kutoka Wi-Fi kwenda LTE hurudi na chanzo tofauti kabisa. Thamani chaguo-msingi za conntrack za Linux ni kipimo muhimu hapa: nf_conntrack_udp_timeout ni sekunde 30 na aina ya utiririshaji ni 120, kwa hiyo handaki tulivu linaweza kupoteza ramani yake muda mrefu kabla mtumiaji kugundua.

Handaki huendelea kuishi kwa sababu itifaki huthibitisha mwenza, si anwani. WireGuard haina hali baada ya kupeana mkono, kwa hiyo pakiti yoyote iliyothibitishwa husasisha kituo cha mwisho kilichohifadhiwa na kufungwa upya hupona kwenye pakiti inayofuata; ndiyo maana persistent-keepalive = 25 ipo, ili kuweka ramani moto wakati haitumiki. --float ya OpenVPN hufanya kazi hiyo hiyo na huruhusu mteja aliyethibitishwa kuendelea kutoka anwani na bandari mpya. Katika builds za 2.4 na 2.5 ambapo float imezimwa kwa chaguo-msingi, kufungwa upya hurejesha kikao na mteja huunganisha tena.

IPsec hufika hapo na sehemu nyingi zinazosonga. IKEv2 hutambua tafsiri kwa kulinganisha hashi za chanzo na lengwa katika mizigo ya kugundua NAT, hubadilika kwenda kufungasha kwa UDP 4500, na hufuata keepalive hadi tuple mpya. Keepalive zinapozuiwa SA hubaki hewani kwenye karatasi wakati trafiki upande mmoja ikisimama kimya.

Seva inaweza kuhusisha nini, na nini haiwezi

Hadithi inayostahili kuuawa ni kwamba tafsiri inakuficha kutoka kwa mtoa huduma. Hubadilisha lebo, si uchunguzi. Lango lililo nyuma ya NAT ya mtoa huduma huona nafasi ya 100.64.0.0/10 au anwani moja ya umma inayoshirikiwa na wateja wengi, na bado inaweza kuhusisha mtiririko na somo la cheti, ufunguo wa umma wa WireGuard, anwani ya handaki iliyotolewa, vihesabu vya baiti na dirisha la muda. Hakuna kati ya hivi linalohitaji anwani yako ya LAN.

Mipaka huenda upande mwingine pia. Anwani inayoshirikiwa kwenye kumbukumbu huelekeza kwenye lango, si kaya; vikao viwili kutoka anwani moja iliyotafsiriwa kwenye bandari tofauti ni vifaa tofauti; anwani moja katika siku mbili tofauti inaweza kuwa wateja wawili wasiohusiana ikiwa bandari ilirejeshwa. Seva inayorekodi funguo za wenza pekee haiwezi kumhusisha mmoja na mteja bila hifadhidata ya akaunti, na seva inayorekodi anwani pekee haiwezi kutofautisha kompyuta mpakato na simu nyuma ya ruta moja.

Linganisha ncha mbili badala ya kukisia

Ili kubaini kilichotokea, nasa muunganisho huo huo kwenye ncha zote mbili kwa wakati mmoja na linganisha tuple, si anwani. Kwenye mteja, kabla ya tafsiri yoyote:

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

Kisha soma ingizo la tafsiri kwenye ruta au lango la CGNAT, na kile hatimaye hufika kwenye seva:

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

Mifumo mitatu hufafanua tofauti nyingi. Bandari ya chanzo kwenye seva inatofautiana na bandari ya ndani wakati lengwa linalingana: tafsiri ya kawaida ya bandari. Anwani ya chanzo kwenye seva ni ya kizuizi cha ISP ambacho si chako: angalau tabaka moja ya ziada ya NAT. Pakiti zinasimama baada ya kipindi cha kutotumika na kuendelea na bandari mpya: ramani imeisha muda, si hitilafu ya uelekezaji. Ikiwa mihuri ya muda iko zaidi ya sekunde moja au mbili, unalinganisha majaribio mawili tofauti.

Mahali tofauti inapovunja mambo

Usumbufu unaoonekana kama hitilafu za seva kwa kawaida huanza hapa. Kanuni ya ufikiaji iliyobandikwa kwa anwani yako ya nyumbani hushindwa baada ya ukodishaji wa ISP kubadilika. Kanuni ya fail2ban inayolingana na anwani iliyotafsiriwa huzuia wateja wote nyuma ya lango hilo kwa wakati mmoja. Mwenza wa tovuti-kwa-tovuti mwenye anwani ya mbali isiyobadilika huacha kuhuisha funguo baada ya kiungo cha simu kubadilika. Itifaki ya handaki ilikuwa sawa; dhana kuhusu tuple ya nje haikuwa.

Mkanganyiko huo huo huonekana upande wa seva. Ikiwa sanduku la VPN lenyewe liko nyuma ya NAT unahitaji uelekezaji wa bandari na njia ya uelekezaji inayofanya kazi; mwongozo wa uelekezaji wa strongSwan hushughulikia hali hiyo kwa IPsec. Seva inayofikiwa kwa anwani ya kibinafsi pekee haioni kamwe tuple iliyotafsiriwa ambayo wateja wake wanawasilisha, na hilo ni tatizo tofauti na wateja kutafsiriwa.

Pitia ukaguzi huu manne kwa mpangilio na usimame kwenye wa kwanza kushindwa:

• Nasa kwenye ncha zote mbili kwa wakati mmoja; thibitisha kwamba bandari ya chanzo, bandari ya lengwa na mihuri ya muda vinalingana.
• Soma orodha ya wenza wa seva kwa anwani aliyo nayo sasa, si ile uliyotarajia.
• Angalia jedwali la conntrack au NAT kwa ingizo na maisha yake yaliyobaki.
• Thibitisha kwamba anwani ya kiolesura cha handaki kwenye mteja inalingana na ile iliyotolewa na seva, si anwani ya LAN.

Ikiwa nasa zote mbili zinakubaliana kuhusu tuple na handaki bado linashindwa, tafsiri si tatizo lako; nenda kwenye kupeana mkono na kwenye jedwali la uelekezaji ndani ya handaki.