Jinsi ya kutuma subnet moja ya faragha tu kupitia VPN

Chagua kati ya njia kwenye mteja, njia anayosukuma seva na vichaguzi vilivyojadiliwa, kisha pitisha subnet moja ya faragha bila handaki kamili.

Subnet moja ya faragha kupitia handaki na kila kitu kingine kwa njia yako ya kawaida ni ombi dogo lenye njia nyingi za kukosea. Matokeo hayaamuliwi na kisanduku cha kuteua kinachoitwa split tunneling, bali mahali uamuzi unatekelezwa: kwenye jedwali la njia la mteja mwenyewe, kwenye njia anayosukuma seva, au kwenye sera inayojadiliwa na pande mbili. Chagua tabaka lisilofaa na utapata ama handaki kamili ambalo hukulitaka kamwe, au njia kuelekea handaki ambalo upande mwingine unakataa kulipokea. Ninatumia jaribio la masharti matatu kabla ya kufungua usanidi wowote, kisha nichague moja ya mbinu zilizo hapa chini.

Masharti matatu yanayoamua muundo

Kwanza, unahitaji kiambishi awali na kifuniko sahihi kutoka kwa mmiliki wa mtandao. Mtandao wa 10.x si kiambishi awali; 10.20.0.0/16 ni kiambishi awali. Hakikisha hautagongana na LAN ya nyumbani, daraja la Docker au VPN nyingine unayoendesha, kwa sababu mtagongano hufanya njia isiwe ya wazi na kerneli huchagua ingizo ambalo hukukusudia.

Pili, ni nani anayejibu trafiki inayorudi. Kuelekeza pakiti ndani ya handaki huipeleka tu hadi seva ya VPN. Ikiwa subnet iko nyuma ya kipanga njia kingine ambacho hakina njia ya kurudi kwenye dimbwi lako la wateja, seva lazima ifiche trafiki, au kipanga njia hicho kijifunze dimbwi lako. Hakuna njia ya upande wa mteja inayorekebisha njia ya kurudi inayokosekana.

Tatu, mahali pa utekelezaji. Wateja wengine husakinisha njia na mfumo wa uendeshaji hufanya mengine. Wengine hujadili sera, na sera ambayo lango halikubali haizalishi handaki kabisa: pakiti hutupwa bila hitilafu iliyo wazi. Tambua ni ipi kati ya hizo mbili iliyo yako kabla ya kuandika chochote.

WireGuard: AllowedIPs ni jedwali la njia

Kwenye mteja, AllowedIPs huorodhesha maeneo yanayoweza kuingia handakini, na wg-quick hubadilisha kila ingizo kuwa njia ya kawaida. Kwa hiyo nusu ya mteja ya kazi hii ni mstari mmoja.

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16

Sasa linganisha ingizo la seva kwa mteja huyo huyo. Linaeleza kile seva itamtumia mteja, ambayo kwa kawaida ni anwani ya handaki ya mteja, si subnet ya faragha.

[Peer]
PublicKey = ...
AllowedIPs = 10.99.0.2/32

Kubadilishana hizi mbili ndilo kosa ninaloliona mara nyingi zaidi. Kuweka 10.20.0.0/16 chini ya sehemu ya peer ya seva kunasema kwamba subnet yote iko nyuma ya mteja huyo, na hiyo ni madai ya tovuti-hadi-tovuti, si ruhusa. Pakiti zisizolingana na AllowedIPs ya peer yoyote hutupwa kimya, kwa hiyo ingizo lisilofaa linaonekana sawa kabisa na tatizo la ukuta wa moto.

Ikiwa unasimamia njia mwenyewe, weka Table = off chini ya [Interface] na uongeze njia unayotaka. Wakati huo hakuna kinachoongezwa kiotomatiki, kwa hiyo njia ni ya kile kinachoinua kiolesura.

OpenVPN: sukuma njia, kisha hakikisha inafika

Kwenye seva ya kawaida mabadiliko ni agizo moja katika usanidi wa seva, kando ya dimbwi la wateja.

push "route 10.20.0.0 255.255.0.0"

Mteja huiongeza anapounganisha. Hali ya kushindwa huonekana wakati wasifu huo huo unasukuma pia redirect-gateway, au wakati mtu ameongeza tayari route-nopull: la kwanza hubadilisha kikao kuwa handaki kamili, na la pili hutupa kila njia iliyosukumwa, ikiwa ni pamoja na yako.

Mteja anayehitaji tabia nyembamba dhidi ya seva ya handaki kamili anapaswa kupuuza sehemu tu ambazo hazitaki. Katika OpenVPN 2.4 na baadaye, pull-filter ipo kwa ajili ya hilo hasa.

pull-filter ignore "redirect-gateway"
route 10.20.0.0 255.255.0.0

Tenganisha familia za anwani: njia ya IPv4 iliyosukumwa haifanyi chochote kwa huduma ya ndani inayotatuliwa kuwa IPv6, na huduma hiyo inashindwa kupitia handaki wakati kila kitu kingine kinaonekana sawa.

Wakati subnet ya faragha haiko kwenye seva ya VPN bali nyuma ya mteja mwingine, seva lazima ifahamishwe. Ongeza faili kwa kila mteja kupitia client-config-dir inayoshirikisha iroute 10.20.0.0 255.255.0.0, pamoja na route inayolingana ili wateja wengine wajifunze njia. Bila iroute seva haina sababu ya kutuma kiambishi hicho kupitia handaki hilo mahususi.

IPsec: vichaguzi vya trafiki lazima vikubaliane

Kwa IPsec hakuna njia ya kusukuma. Pande mbili hujadili ni anwani zipi zinaishi ndani ya handaki, na trafiki nje ya vichaguzi vilivyokubaliwa haisimbishwi na haipiti kupitia hilo. Kwenye mteja wa strongSwan vichaguzi viko wazi.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Ikiwa lango limewekwa na 0.0.0.0/0 pande zote mbili, ubana wa IKEv2 kwa kawaida hupunguza SA mtoto hadi makutano ya mapendekezo mawili, ambayo ni matokeo unayotaka. Baadhi ya malango hukataa badala yake pendekezo lisilolingana na vichaguzi vyake vilivyowekwa, na kumbukumbu huonyesha SA mtoto iliyoshindwa badala ya malalamiko ya uelekezaji. Hilo linapotokea mabadiliko ni ya lango, kwa sababu njia ya mteja haiwezi kuunda handaki kwa kichaguzi ambacho upande mwingine hautakubali.

Kwenye Windows mteja aliyejengwa ndani huficha uamuzi huo huo nyuma ya mipangilio miwili. Mgawanyo wa handaki lazima uwe umewashwa, na kiambishi awali lazima kisajiliwe kwenye wasifu.

Set-VpnConnection -Name Office -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.20.0.0/16

Usajili wa kiambishi awali ndio unaoufanya ustahimili muunganisho upya, jambo ambalo njia iliyoongezwa kwa mkono haifanyi.

Weka sehemu ya mwisho na DNS nje ya uamuzi

Sehemu ya mwisho ya VPN lazima ibaki ikifikiwa bila handaki, vinginevyo handaki huanguka ndani yake yenyewe. Wakati 10.20.0.0/16 pekee inaelekezwa hilo ni kiotomatiki, kwa kuwa sehemu ya mwisho ni anwani ya umma. Kwenye wasifu wa handaki kamili sivyo, na mteja anahitaji njia ya wazi ya mwenyeji kuelekea sehemu ya mwisho kabla handaki halijainuka.

DNS ni uamuzi wa pili ambao usukaji wa njia hauchukui kwa niaba yako. Majina ya ndani kwa kawaida hutatuliwa kupitia kitatuzi ambacho mtandao wa faragha pekee unaweza kufikia. Ikiwa seva inasukuma seva ya DNS, kila jina hupita ndani yake; ikiwa haifanyi hivyo, majina ya ndani ama yanashindwa au yanatatuliwa hadharani kwenda kitu usichokusudia. DNS iliyogawanywa huweka kikoa kimoja cha utafutaji kwenye kitatuzi cha ndani, lakini hilo linategemea msaada wa mteja, kwa hiyo lichukulie kama kazi yake yenyewe na si athari ya kando ya uelekezaji.

Thibitisha, kisha anzisha upya na uthibitishe tena

Majaribio matatu hushughulikia swali la uelekezaji. Uliza kerneli anwani ya mbali itakwenda wapi, chukua kitu kutoka ndani ya subnet, kisha thibitisha kwamba ombi la kawaida la umma bado linatoka kupitia muunganisho wako wa kawaida.

ip route get 10.20.5.7
curl -sS http://10.20.5.7/health
curl -sS https://ifconfig.me

Mstari wa kwanza unataja kiolesura. Ikiwa unataja kiolesura chako cha kimwili, njia haikufika kamwe. Kwenye Windows Find-NetRoute -RemoteIPAddress 10.20.5.7 hujibu swali hilo hilo, na jaribio la mwisho bado linapaswa kuonyesha anwani yako ya kawaida na si ya seva ya VPN.

Kisha anzisha upya. Njia zilizoongezwa kwa mkono hupotea, wakati njia kutoka kwa wasifu, kutoka usanidi uliosukumwa au kutoka AllowedIPs hurudi. Ikiwa ufikiaji mwembamba unafanya kazi kabla ya kuanzisha upya na unashindwa baada, kosa liko katika jinsi handaki linavyoanza, si katika njia yenyewe.

Kabla ya kusema limekamilika, thibitisha mambo manne: kiambishi awali kilitoka kwa mmiliki wa mtandao na hakiingiliani na kitu chochote cha ndani, njia ya kurudi ipo au kanuni ya ufichaji inachukua nafasi yake, mbinu uliyoweka ndiyo inayotekeleza uelekezaji kwenye jukwaa lako, na majaribio yale yale hupita baada ya kuanzisha upya safi. Maelezo ya strongSwan kuhusu upelekaji yanafaa kusomwa ikiwa njia ya kurudi ni sehemu inayoendelea kushindwa.

Makala zinazohusiana