Watumiaji wa mbali hawafikii tovuti ya pili kupitia kitovu cha VPN

Mtumiaji wa mbali anajiunga na kitovu, anafikia seva ya faili kwenye LAN ya kitovu chenyewe, na kila kitu kinaonekana sawa. Kisha anafungua sehemu kwenye 10.20.0.50 huko makao makuu, ambayo kitovu huifikia kupitia handaki tofauti la tovuti-hadi-tovuti, na muda wake unaisha. Handaki zote mbili ziko juu na vihesabu vyote viwili vinapanda, kwa hivyo hakuna handaki iliyovunjika. Kuvuka kitovu ni maamuzi matatu ya uelekezaji kwenye vifaa vitatu, na handaki hubeba tu viambishi awali ambavyo ilijengwa kwa ajili yake. Hapa kuna mpangilio ninaokagua, na amri inayoonyesha ikiwa kila hatua ni kweli.

Usafiri unahitaji utafutaji tatu, si handaki moja

Kila kifaa hufanya ulinganifu wake wa kiambishi awali kirefu zaidi na kuisahau. Kompyuta ya mkononi lazima itume 10.20.0.50 ndani ya handaki badala ya kwa kipanga njia chake cha ndani. Kitovu lazima kichukue kifurushi kilichofika kwenye kiolesura cha ufikiaji wa mbali na kukabidhi kwa kiolesura cha tovuti-hadi-tovuti. Makao makuu lazima yatume jibu la anwani ya mtumiaji kurudi kupitia handaki. Yoyote ya hitilafu hizo tatu huonekana sawa kwenye kivinjari: ukimya.

Ndiyo sababu kujaribu kila handaki peke yake kunathibitisha kidogo sana. Kupiga ping anwani ya LAN ya kitovu hufanya uamuzi wa kwanza, na kupiga ping kitovu kutoka makao makuu hufanya wa tatu. Kifurushi kinachoshindwa kina chanzo cha bwawa la watumiaji na lengo la tovuti ya pili, kwa hivyo andika kwanza viambishi hivyo. Hapa bwawa ni 10.80.0.0/24, LAN ya kitovu ni 10.10.0.0/24 na makao makuu ni 10.20.0.0/24.

Sukuma kiambishi cha mbali kwa mteja wa mbali

Kwenye OpenVPN seva ya ufikiaji wa mbali mteja hujifunza njia wakati wa kuunganisha. Bila push, mteja wa handaki iliyogawanywa hutuma 10.20.0.50 kwa lango lake mwenyewe na kifurushi hakiingii kamwe kwenye handaki.

push "route 10.20.0.0 255.255.255.0"

Njia iliyosukumwa huanza kutumika mteja anapounganisha, kwa hivyo mtumiaji anayebaki mtandaoni haoni chochote hadi aunganishe tena. Hakikisha kwenye mteja: ip route get 10.20.0.50 kwenye Linux, route print kwenye Windows. Matokeo yanapaswa kutaja kiolesura cha handaki.

push haisaidii kitovu. Ni ujumbe kwa mteja, si njia kwenye seva na si ruhusa ya kupeleka, kwa hivyo kitovu chenye mstari kamili wa push bado kinatupa mtiririko hatua moja baadaye. Hii ndiyo sababu ya kawaida watu kuhitimisha kuwa push imeshindwa.

Ipe kitovu njia halisi ya kutoka

Kitovu kinahitaji hatua yake inayofuata kwa kiambishi cha makao makuu. Kwenye handaki lenye uelekezaji hiyo ni njia ya kawaida kupitia kiolesura cha tovuti-hadi-tovuti, na amri moja inaonyesha njia iliyochaguliwa na chanzo kilichochaguliwa:

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

Ambapo mguu wa tovuti-hadi-tovuti wenyewe ni OpenVPN, njia inaweza kuishi katika usanidi huo ukiwa na anwani ya handaki ya mshirika kama lango: route 10.20.0.0 255.255.255.0 172.30.0.2. Lango si la hiari. Ukiliacha, hatua inayofuata inaanguka kwenye chaguo-msingi la utekelezaji, ambalo hutofautiana kati ya mteja wa mbali mmoja na kitovu chenye washirika wengi.

IPsec inayotegemea sera ni tofauti: kiini cha kitovu hutuma kifurushi kwa lango lake la kawaida la LAN na sera huikamata ikiwa inatoka, kwa hivyo njia ya handaki ama haifanyi kitu au hupeleka trafiki kando ya sera. Angalia chanzo kwenye amri hapo juu, kwa sababu 10.10.0.1 badala ya anwani ya bwawa inamaanisha kiini kilichagua anwani ambayo upande wa mbali utaikataa. iroute pia si jibu; inaiambia seva mteja gani anamiliki subnet nyuma ya handaki yake mwenyewe, si wapi kupeleka trafiki kwa tovuti ya tatu.

Panua upande wa mbali hadi bwawa la watumiaji

Makao makuu tayari yanashughulikia LAN ya kitovu, 10.10.0.0/24. Bwawa la watumiaji ni kiambishi cha pili na lazima kiwe pia kwenye vichaguzi, vinginevyo hakuna sera inayoshughulikia jibu lililoelekezwa kwa 10.80.0.25. Kila mshirika hutaja jozi hiyo hiyo ya seti za viambishi kutoka upande wake:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

local_ts ya kifaa kimoja ni remote_ts ya kingine. Nakili kizuizi cha kitovu kwenda makao makuu na jozi hiyo inageuka, kwa hivyo SA ya mtoto haipanda kamwe.

Sintaksia ya zamani ya ipsec.conf hutumia leftsubnet iliyotenganishwa na koma. Muungano wa usalama unaoendelea huhifadhi vichaguzi vilivyojadiliwa, kwa hivyo anzisha tena handaki baada ya kuhariri. Kichaguzi kilichobadilishwa saa 10:00 na kujaribiwa dhidi ya SA iliyopanda saa 09:40 bado kinashindwa, wakati faili ya usanidi inaonekana sahihi wakati wote.

Kisha angalia hatua ya mwisho. ip route get 10.80.0.25 kwenye ncha ya mbali inapaswa kuelekeza ndani ya handaki. Ikiwa huduma inatumia kipanga njia cha LAN kama lango lake chaguo-msingi, kipanga njia hicho pia kinahitaji njia ya kurudi, vinginevyo jibu hufa hapo. Kuendesha tcpdump -ni eth1 host 10.80.0.25 kwenye sehemu hiyo kunaonyesha ikiwa jibu liliondoka kabisa kwenye ncha.

Ruhusu mtiririko kwenye kitovu

Upelekaji lazima uwe umewashwa na njia iruhusiwe. Punguza kanuni kwa viambishi viwili badala ya kukubali kila kitu kati ya violesura.

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

Uchujaji wa njia ya kurudi ni hitilafu ya kimya kando yake: violezo viwili vikiwa kwenye violesura tofauti, rp_filter=1 inaweza kutupa jibu wakati kihesabu cha kanuni ya kukubali hakisogei kabisa. Linganisha iptables -vnL FORWARD kabla na baada ya jaribio. Kanuni isiyoongezeka kamwe haifikiki, kwa hivyo angalia tabaka moja chini badala ya kuiandika upya.

Ikiwa kundi moja tu linahitaji usafiri, weka njia katika faili ya kila mteja chini ya client-config-dir badala ya kupanua push ya jumla. Source NAT kwenye kitovu pia huondoa hitaji la njia ya kurudi upande wa mbali, lakini huficha anwani ya mtumiaji, kwa hivyo kumbukumbu za tovuti ya mbali na kanuni zinazotegemea anwani huacha kutofautisha watumiaji.

Hakiki kutoka kwa mteja, kisha rudi nyuma kwa mpangilio wa kinyume

Jaribu bandari ya TCP, si ICMP tu, kwa sababu ping inaweza kupita wakati huduma inabaki imezuiwa. nc -vz 10.20.0.50 445 na traceroute -n 10.20.0.50 kutoka kwa mteja zinaonyesha ikiwa hatua ya pili ni anwani ya handaki ya kitovu. Kwenye kitovu, tcpdump -ni tun0 host 10.20.0.50 na chujio sawa kwenye kiolesura cha tovuti-hadi-tovuti: ombi kwa zote mbili bila jibu kwa yoyote huhamishia tatizo upande wa mbali.

Kisha jaribu kitu ambacho lazima kibaki kimezuiwa. Ikiwa mwenyeji ambaye bwawa halipaswi kumfikia kamwe pia anajibu, umefungua zaidi ya usafiri na unapaswa kupunguza kanuni. Kitovu kinachopeleka kila kitu kwa kila tawi hupita jaribio la kwanza na kushindwa la pili.

Weka orodha ya kurudi nyuma, kwa sababu vitu vinne vilibadilika na vitatu ni rahisi kusahau: njia iliyosukumwa, njia ya kitovu, vichaguzi na kanuni za ngome. Vighairi kinyume chake, anzisha tena SA, na mruhusu mtumiaji mmoja aunganishe tena. Kurudi nyuma kwa sehemu huacha njia inayoelekeza kwenye handaki ambalo halingani tena, na hilo ni gumu kusoma kuliko ukimya wa awali. Mwongozo wa OpenVPN 2.6 unaandika push, route na iroute kwa toleo lako.