OpenVPN inaendelea kusukuma njia za zamani? Angalia kile ilichopakia

Unaongeza njia, unazindua huduma upya, unaunganisha tena, na jedwali la mteja linaonekana kama kabla. Mambo mawili tofauti yanaweza kuwa kweli: seva haikupakia mabadiliko yako, au mteja hakufunga kile alichopokea. Hawana kitu cha pamoja isipokuwa dalili, kwa hiyo hatua ya kwanza ni kujua ni ipi kati ya mbili uliyonayo.

Ulinganisho hapa chini unaenda kutoka kwa mchakato kwenda nje, kwa sababu mchakato ndio mamlaka pekee ya kujua faili ipi inatumika.

Faili uliyoihariri na faili ambayo mchakato unasoma

Anza na unit na mstari wa amri uliouzalisha. Kwenye mwenyeji wa systemd, systemctl cat openvpn@server huchapisha mstari wa ExecStart, na instance unit kwa kawaida hupata njia yake ya usanidi kutoka jina la instance, kwa hiyo daemon iliyoanzishwa kama openvpn@office husoma faili tofauti na ile iliyoanzishwa kama openvpn@server. Linganisha hilo na argv ya mchakato unaoendelea. Zana ya usimamizi wa usanidi inaongeza njia nyingine ya kupoteza mabadiliko: inaweza kuandika faili sahihi mahali ambapo unit haitaji kamwe, na hapo utekelezaji wenye mafanikio unaonekana kama hakuna kitu.

Mihuri ya muda huamua hili haraka: ikiwa faili ni mpya zaidi ya muda wa kuanza kwa mchakato, mchakato haukuweza kuisona. Firmware ya kipanga njia inaongeza kesi ya tatu, kwa sababu modeli nyingi huhifadhi mipangilio yao kwenye flash na hujenga upya usanidi wakati wa kuwasha, jambo linalofanya uhariri wa faili kwenye diski kuwa tabaka lisilofaa kabisa.

Seva inasukuma nini na mteja anafunga nini

Njia iliyosukumwa lazima ipite vichujio viwili. Kwenye seva lazima iwe kwenye usanidi uliopakiwa, sio kwenye kizuizi kilichotolewa maoni au faili maalum ya mteja ambayo jina lake halingani. Kwenye mteja, pull lazima iwe imewezeshwa na hakuna pull-filter yoyote inayoweza kutupa chaguo hilo. Unganisha kwa verbosity 4 na usome chaguo zilizosukumwa ambazo mteja anaripoti: ikiwa njia inaonekana kwenye orodha hiyo, seva imefanya kazi yake na mteja ndiye anayechagua kutokufunga.

Faili maalum za mteja ni chanzo cha kawaida cha mkanganyiko. Faili iliyopewa jina la common name ya cheti husukuma chaguo kwa mteja huyo pekee, na tofauti ya herufi moja husimamisha usukumaji kimya kimya, bila hitilafu upande wowote. Seva hurekodi common name iliyoiona wakati wa kuunganisha, kwa hiyo linganisha thamani hiyo na jina la faili, sio na kile unachofikiri ni jina la mteja.

Kiambishi kilichosukumwa na njia ya kurudi ni shida mbili tofauti

Mteja anayepuuza kwa makusudi redirect-gateway ili kuhifadhi njia yake ya ndani ya intaneti huunda pengo la pili lisilohusiana. Uchunguzi wa seva hufikia anwani ya handaki lakini majibu hayafiki kamwe, kwa sababu jibu lililoelekezwa kwa IP ya handaki ya seva hupitishwa kupitia lango la kawaida la chaguo-msingi la mteja. Hapa njia ya subnet iliyosukumwa haina kosa; kinachokosekana ni njia inayorudisha trafiki ya mtandao wa handaki wa seva kupitia kifaa cha handaki.

Kuongeza njia hiyo kwenye mteja hurekebisha majibu kwa uchunguzi unaoanzishwa na seva. Haichukui nafasi ya njia ya subnet iliyosukumwa, na kinyume chake pia ni kweli, kwa sababu zote mbili zinaelezea mielekeo tofauti ya safari.

Linganisha majedwali kwenye ncha zote mbili

Baada ya mabadiliko yoyote, unganisha tena na usome jedwali la mteja kwa kiambishi kilichosukumwa na kwa kifaa cha handaki. Kisha jaribu kwa mielekeo yote miwili: kutoka kwa mteja hadi mwenyeji kwenye subnet iliyosukumwa, na kutoka kwa mwenyeji huyo kurudi kwa mteja. Njia iliyopo lakini haibebi trafiki inamaanisha moja ya mambo matatu: upande wa mbali hausambazi, firewall inatupa mtiririko, au jibu halina njia ya kurudi.

Weka vitambulisho vitatu pamoja: njia ya usanidi, jina la unit au instance, na utambulisho wa mteja uliotumia kupima.

Vitatu hivi hufanya tukio lijalo liwe ukaguzi wa dakika tano badala ya uchunguzi mpya, na ndivyo mwenzako anahitaji handaki inapokuwa shida ya mtu mwingine.

Shida ya njia inayostahimili kuwasha upya mara nyingi si shida ya upangaji wa njia hata kidogo; hitilafu iko juu ya jedwali unaloendelea kusoma.