Kwa nini wateja wa OpenVPN hukosa vichaguzi vya IPsec vya lango
Ping kutoka lango huthibitisha mtiririko tofauti. Fuatilia dimbwi la wateja kupitia njia iliyosukumwa, vichaguzi vya IPsec, mnyororo wa upelekaji na njia ya jibu.
Tuma ping kutoka lango kuelekea mwenyeji aliye nyuma ya handaki la IPsec la mbali na hujibu kwa usafi, kwa hiyo handaki linaonekana likiwa zuri na tikiti inasonga mbele. Kisha mteja aliyeunganishwa anajaribu mwenyeji yuleyule na hapati chochote. Ping hiyo haikuwa kamwe ushahidi wa mtiririko wa mteja, kwa sababu ilitoka na anwani ya chanzo ya lango lenyewe na ikalingana na kichaguzi kingine cha IPsec. Kuelewa kwa nini hali hizi mbili zinatofautiana ndiyo sehemu kubwa ya marekebisho.
Ping ya lango hujaribu mtiririko ambao mteja wako hautumii kamwe
Anwani ya chanzo huamua sera ipi inatumika. Pakiti inayozalishwa kwenye lango hutoka na anwani kutoka LAN yake ya ndani au kutoka sehemu ya mwisho ya handaki, na sera inayoilingana nayo iliandikwa mahsusi kwa hali hiyo. Pakiti ya mteja hufika kwenye kiolesura cha OpenVPN ikiwa na anwani kutoka dimbwi la wateja, ambayo ni kichaguzi tofauti kabisa.
Ndiyo sababu hitilafu inaonekana kama tatizo la uelekezaji wakati kwa kweli ni tatizo la upeo wa sera. Ufikivu kutoka lango huthibitisha kwamba mwenzake yuko hai na kwamba mapendekezo yalijadiliwa, na haithibitishi chochote kuhusu kama dimbwi linalindwa.
Sukuma kiambishi awali cha mbali ambacho programu inahitaji kweli
Chukua jozi ya mfano 10.8.0.0/24 kwa wateja waliounganishwa na 172.30.239.0/25 kwa mtandao wa mbali unaolindwa. Kile mteja anahitaji ni njia kuelekea kiambishi awali cha pili, si kuelekea LAN ya lango na si kuelekea anwani nyingine ya handaki. Njia iliyosukumwa kwenye dimbwi ndiyo inayomfanya mteja kuikabidhi trafiki hiyo kwa lango. Bila hiyo pakiti haifikii uamuzi wa sera unaotatua.
Kwenye seva ya Community inayokubali njia zilizosukumwa, agizo huchukua mask halisi: push "route 172.30.239.0 255.255.255.128". Access Server husanidi lengo lilelile kupitia mipangilio ya mtandao wa kibinafsi au kanuni za ufikivu za toleo lililosakinishwa, huku hali ya uelekezaji au utafsiri ikichaguliwa kwa makusudi. Kuhariri minyororo ya firewall iliyozalishwa badala ya usanidi unaomiliki ni njia ambayo usakinishaji unaofanya kazi unakuwa hauwezi kuzalishwa tena.
Baada ya kuunganisha, soma jedwali la uelekezaji la mteja badala ya nia ya seva. Njia inayofunika dimbwi pekee inamaanisha kwamba usukumi haukufika, na njia chaguo-msingi kupitia handaki ni pana kuliko hitaji hili na itakushangaza baadaye. Angalia mask na kiambishi awali, kwa sababu /25 iliyosukumwa kama /24 hutuma trafiki ya anwani jirani kwenye njia isiyoweza kuibeba. Kisha thibitisha kwamba mteja alichagua kiolesura cha handaki kwa lengo hilo.
Fanya vichaguzi vijumuishe dimbwi la wateja
Kwa ufikivu wa uelekezaji unaohifadhi anwani za wateja, sera ya IPsec lazima ilinde trafiki kati ya dimbwi na kiambishi awali cha mbali. Vichaguzi vilivyoandikwa kwa LAN ya lango lenyewe huruhusu ping na hutupa ombi la mteja, na hiyo ndiyo tofauti isiyo sawa iliyoanzisha uchunguzi huu.
Kagua sera iliyojadiliwa pamoja na mapendekezo yaliyosanidiwa, kwa mfano kwa ipsec statusall kwenye strongSwan au amri sawa ya hali kwa utekelezaji wako. Katika IPsec inayotegemea sera njia ya kawaida inaweza kuelekeza kiolesura halisi wakati trafiki inayolingana ikiwa bado imesimbwa, kwa hiyo ukosefu wa kifaa cha handaki hauthibitishi chochote. Linganisha jozi za vichaguzi na dimbwi na kiambishi awali uliyoandika.
NAT ya chanzo ya jumla kwenye lango inaweza pia kuvunja ulinganifu. Ikiwa kanuni ya masquerade itaandika upya chanzo cha mteja kabla ya ukaguzi wa sera, pakiti haionekani tena kama kichaguzi ulichoandika. Hii ni sababu moja kwa nini kanuni pana ya masquerade ni marekebisho mabaya kwa VPN ya pili: inabadilisha sera ipi inatumika na anwani ipi upande wa mbali hurekodi. Ondoa trafiki unayokusudia kuelekeza, au itafsiri kwa makusudi na usasishe vichaguzi.
Chagua uelekezaji au utafsiri kwa makusudi
Uelekezaji huweka anwani ya mteja ionekane kwa upande wa mbali, kwa hiyo kumbukumbu za mbali na kanuni kwa kila chanzo zinabaki na maana, na unahitaji lango la mbali lijue njia ya kurudi kwenye dimbwi. Utafsiri huficha dimbwi nyuma ya anwani moja, jambo ambalo huondoa tatizo la njia ya kurudi na huharibu utambulisho kwa kila mteja.
Chagua muundo mmoja na uandike, kwa sababu zote mbili zinahitaji vichaguzi tofauti na mpangilio tofauti wa firewall. Masquerade iliyotumika nusu huangukia katikati na haikidhi yoyote. Uchaguzi ulioandikwa pia ndio unaomruhusu mhandisi anayefuata kutofautisha hitilafu na uamuzi wa makusudi.
Funga mzunguko kwenye upelekaji na jibu
Lango lazima lipeleke itifaki na lengo unalokusudia, ambayo inamaanisha upelekaji wa IP umewashwa na mnyororo wa upelekaji unaoruhusu jozi. Kisha upande wa mbali lazima urudishe majibu kupitia njia ya IPsec, na huo ni uamuzi wa uelekezaji kwenye lango lao na si lako. Nusu zote mbili ni usanidi wa kawaida, na zote mbili huachwa nusu kwa urahisi. Zijaribu kwa tofauti ili kanuni ya upelekaji inayokosekana isichukuliwe kama handaki lililovunjika.
Thibitisha kwa ombi moja halisi kutoka mteja hadi programu, ukilitazama likipita kiolesura cha OpenVPN, uamuzi wa IPsec na mwenyeji wa mbali. Kagua jibu kama uchunguzi tofauti, kwa sababu ombi linalofika na jibu lisilorudi kamwe huonekana sawa kutoka mahali pa mteja. Ombi moja lililofuatiliwa lina thamani zaidi ya idadi yoyote ya ping kutoka lango.
Weka idhini ya lengo ikiwa nyembamba unapojaribu, na thibitisha kwamba mteja asiye na kanuni hawezi kufikia huduma. Njia iliyosakinishwa pamoja na muungano ulioanzishwa si kitu kimoja na ufikivu uliotolewa.