VPN kwenye rauta au uelekezaji wa lango: kipi kinashinda?

Rauta yenyewe humaliza VPN, na kanuni ya zamani ya uelekezaji bado inatuma lango lile lile la UDP kwa mashine iliyo kwenye LAN. Ni moja tu kati ya hizo inayoweza kuwa kituo halisi cha mwisho, na kerneli haiamui baina yao. Tafsiri ya lengwa huandika upya pakiti kabla huduma ya ndani haijaulizwa, kwa hiyo mchakato wa VPN husubiri trafiki ambayo tayari imetumwa mahali pengine. Kazi ni kuamua nani anamiliki lango, kisha kanuni zikubaliane.

Lango moja, wamiliki wawili wanaodai

Seva ya VPN inayofanya kazi ndani ya rauta inahitaji idhini ya kuingia inayoelekea kwenye soketi yake mwenyewe. Ingizo la NAT la lengwa kwa lango hilo hilo huelekea mahali pengine kabisa: anwani ya LAN na uamuzi wa uelekezaji. Hizi ni vituo tofauti vya mwisho vyenye kumbukumbu tofauti na njia tofauti za kushindwa. Kidokezo cha kawaida ni kwamba familia moja ya anwani inafanya kazi na nyingine haifanyi, kwa sababu ingizo lililobaki liliandikwa kwa familia moja na halikupitiwa upya kamwe.

Andika madai kabla ya kuhariri: familia, anwani ya nje, usafirishaji, lango na lengwa lililotafsiriwa.

Tafsiri hufanyika kabla ya ukaguzi wa ndani

NAT ya lengwa hubadilisha lengwa la pakiti katika hatua ya kabla ya uelekezaji, kabla kerneli haijachagua kati ya uwasilishaji wa ndani na uelekezaji. Mara lengwa linapokuwa mwenyeji wa LAN, pakiti inachukua njia ya uelekezaji. Kanuni za kuingia kwa soketi ya rauta yenyewe hazizingatiwi kamwe, ndiyo sababu kumbukumbu ya VPN inabaki tupu wakati mteja anasubiri.

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

Mpangilio huo ndio utaratibu wote, na miingiliano ya vifaa huificha nyuma ya visanduku vya kuchagua bila kuubadilisha. Njia ya pakiti bado inaamuliwa na mmiliki wa lengwa.

Ikiwa mwenyeji wa LAN ndiye kituo cha mwisho kinachokusudiwa, uelekezaji ni sahihi na rauta haipaswi pia kusikiliza lango hilo.

Bakiza ramani moja na uondoe nyingine

Orodhesha maingizo ya NAT kwa lango hilo na familia kisha chagua anayebaki:

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

Ingizo la TCP lenye namba hiyo hiyo halihusiki na kushindwa kwa UDP, na kuyachukulia kama kitu kimoja husababisha kufuta kanuni isiyo sahihi. Wakati soketi ya ndani inapaswa kushinda, mmiliki wa ramani inayogongana huondoa au kuandika upya ingizo hilo moja, na idhini ya kuingia kwa lango la rauta yenyewe hubaki mahali pake. Uelekezaji usiohusiana, njia ya usimamizi na nakala ya seti ya kanuni zote zinapaswa kustahimili mabadiliko hayo.

Ikiwa VPN inaishi kwenye mwenyeji tofauti, uelekezaji ndio kitu sahihi. Huduma iliyo kwenye kontena au mashine pepe inaweza kuhitaji lango lililochapishwa hata wakati sanduku linaitwa rauta, kwa hiyo fuata soketi na nafasi yake ya majina, sio lebo iliyo kwenye sanduku.

Thibitisha mmiliki kutoka nje

Jaribu kila familia kivyake, kwa sababu muunganisho wa IPv6 unaoishia kwenye rauta hausemi kitu kuhusu muunganisho wa IPv4 unaoelekezwa upya na kanuni ya zamani. Soma kumbukumbu ya huduma inayopokea ili kuona kituo kipi cha mwisho kilijibu, na chukulia ujumbe wa mafanikio wa mteja kama ushahidi hafifu. Mtiririko mpya unahitajika kwa jaribio lenye maana. Tuma uchunguzi kutoka mwenyeji wa nje kwa nc -zvu 203.0.113.7 1194 na soma kumbukumbu ya mshindi kwa journalctl -u openvpn@server -n 20. Msikilizaji wa rauta hurekodi muunganisho wenyewe, wakati mwenyeji wa LAN hurekodi kwenye huduma yake.

Ufuatiliaji wa miunganisho huweka mitiririko iliyopo kwenye ramani yao ya awali, kwa hiyo kikao kilichothibitishwa kinaweza kuishi zaidi ya kanuni uliyoifanya upya sasa hivi.

Baada ya kituo cha mwisho kinachokusudiwa kujibu kwa ukaguzi wake wa kawaida wa utambulisho, jaribu rasilimali ya faragha nyuma ya handaki. Kufikia msikilizaji wa nje ni hatua ya kwanza tu; uelekezaji wa ndani na idhini ya programu ni matokeo tofauti.