Anwani mbili za huduma kwenye mteja mmoja wa OpenVPN: iroute na lo

Programu hujibu kwenye anwani yake ya handaki, na anwani uliyoiandika kwa ajili yake haiendi popote. Hakuna kitu kwenye kumbukumbu ya OpenVPN kinacholalamika, mwenzake anaonekana ameunganishwa, na kitovu kinaorodhesha mteja mmoja hasa. Pengo ni kwamba anwani ya pili kwenye mteja ni mambo mawili tofauti: mwenyeji lazima awe nayo, na kitovu lazima kijue ni mwenzake gani anayeimiliki. Shughulikia kimoja bila kingine na trafiki ama inakufa kwenye kitovu au inafika bila njia ya kurudi nyumbani.

Jina ni la ndani, umiliki ni wa mbali

Anwani ya handaki hujadiliwa, kwa hivyo pande zote mbili huijifunza wakati wa kupeana mikono. Anwani ya ziada ya huduma haijadiliwi kabisa, ndiyo sababu kuiongeza hakubadilishi chochote kwenye kitovu kwa yenyewe. Mteja anaweza kuimiliki anwani mara moja na seva bado itatuma trafiki hiyo kwenye njia yake ya kawaida au kuiacha. Rekodi mbili lazima ziundwe, katika sehemu mbili tofauti.

Kwa mteja anwani ni ya mwenyeji, na loopback ni nyumba ya asili kwa utambulisho wa huduma ambao haupaswi kuonekana kwenye kiungo halisi. Kwenye kitovu ramani ya mwenzake-hadi-kiambishi ni tangazo tofauti ambalo seva pekee husoma. Hakuna rekodi inayodokeza nyingine.

Weka safu mbili tofauti pia kwenye maelezo yako. Anwani zilizo kwenye mfano ni thamani za nyaraka, na kuzipishana na LAN halisi ni njia ya haraka zaidi ya kufanya usanidi unaofanya kazi uonekane umeharibika.

Ongeza anwani kwa mteja kwa kudumu

Weka anwani ya huduma kwenye loopback na kiambishi cha mwenyeji, ili mwenyeji aichukulie kama pembejeo la ndani na si kama mtandao mdogo wa kufikiwa. ip address add 10.66.0.10/32 dev lo hufanya hivyo kwa anwani moja, na kurudia amri kwa anwani ya pili huiga huduma mbili.

Iendeshe kama jaribio la mara moja, kisha ihamishie kwenye kile kinachomiliki usanidi wa mtandao wa mwenyeji, kwa sababu nyongeza ya wakati wa utekelezaji hupotea unapowasha upya na nakala hurundikana kati ya muunganisho upya. Kitengo cha systemd kilichopangwa baada ya mtandao ni chaguo moja, na msimamizi wa mtandao wa usambazaji ni jingine. Chochote unachochagua, anwani lazima iwepo kabla programu haijafungwa, vinginevyo huduma inaibuka kwenye soketi isiyo sahihi. Thibitisha kwa ip address show dev lo baada ya kuwasha upya na si baada ya amri ya mkono.

Kufunga ni uamuzi tofauti na uanwani. Programu inayosikiliza kwenye kila anwani hupokea trafiki kwenye violesura ambavyo hukukusudia kamwe, kwa hivyo ielekeze kwenye anwani maalum ya huduma. Ndipo sera ya pembejeo ya ndani inakuwa na kitu cha kulinganisha kwa usahihi.

Idai kwenye faili ya CCD ambayo kitovu husoma kweli

Kwenye seva tamko la umiliki huenda kwenye faili ya kila mteja inayochaguliwa na jina la kawaida lililothibitishwa, ndani ya saraka inayotajwa na client-config-dir. Mstari ni iroute 10.66.0.10 255.255.255.255, mmoja kwa kila anwani, na huambia seva ni mwenzake gani anapaswa kupokea trafiki kwa lengo hilo.

Maelezo mawili huvunja hii kwa kimya. Jina la faili lazima lifanane na jina ambalo seva hutumia kweli, ambalo hutofautiana wakati username-as-common-name iko kwenye mchezo. Na iroute hufanya kazi tu katika hali ya TUN na saraka ya usanidi wa mteja iliyosanidiwa, kwa hivyo mstari huo haufanyi chochote kwenye usambazaji wa daraja. Ongeza mistari kwenye faili iliyopo badala ya kuibadilisha, kwa sababu inaweza kuwa tayari ina anwani isiyobadilika au chaguo za push. Rejea ya OpenVPN 2.6 huandika saraka na agizo la umiliki.

Kiini cha kitovu chenyewe pia kinahitaji njia kuelekea maeneo hayo, ili trafiki inayozalishwa ndani iingie kwenye mchakato wa handaki. route 10.66.0.10 255.255.255.255 kwenye usanidi wa seva hushughulikia trafiki ambayo seva yenyewe huizalisha, wakati wateja wengine wanahitaji push "route 10.66.0.10 255.255.255.255" ili wao wenyewe wajifunze lengo.

Uelekezaji na uidhinishaji hubaki tofauti. Njia inayosukumwa humwambia mteja mahali pa kutuma pakiti na haitoi chochote; huduma bado inapaswa kumpokea mpigaji simu kwa masharti yake.

Angalia sera ya pembejeo na njia ya jibu

Pakiti iliyoelekezwa kwa jina hufika kwa mwenyeji anayemiliki kama pembejeo la ndani, kwa hivyo swali ni kama ukuta wa moto wa ndani unaruhusu chanzo hicho na mlango huo. Ruhusu mlango maalum wa huduma kutoka safu ya vyanzo vya VPN badala ya kufungua anwani yote.

Majibu yanahitaji njia ya kurudi kwa mpigaji simu. Kwa mpigaji simu ndani ya dimbwi la kawaida la handaki njia hiyo ipo tayari, kwa sababu kifaa cha handaki huibeba. Mpigaji simu nyuma ya mtandao mwingine ulioelekezwa anahitaji pia njia ya kurudi ya mtandao huo, na hapa ndipo usanidi usio na usawa hupoteza pakiti.

Jihadharini na msikilizaji wa pili kwenye mlango huo huo uliofungwa kwa anwani tofauti, kwa sababu kiini huwasilisha kwa soketi inayolingana na matokeo huonekana ya nasibu. Angalia kwa ss -lntp na uthibitishe kwamba anwani iliyofungwa ni jina la huduma. NAT ya chanzo haihitajiki hapa, na kuiongeza huficha utambulisho wa mpigaji simu ambao kumbukumbu zako zinategemea.

Jaribu anwani na umiliki kwa tofauti

Jaribu kwa hatua mbili. Kwanza thibitisha kwamba mwenyeji anayemiliki anaweza kufikia huduma kwenye jina lake kutoka kwake mwenyewe, jambo ambalo hutenganisha matatizo ya kufunga na ukuta wa moto na uelekezaji. Kisha jaribu kutoka kwa mpigaji simu halisi wa VPN ukitumia uthibitishaji wa programu yenyewe. Wakati wa kwanza unapita na wa pili unashindwa, sehemu inayokosekana iko upande wa kitovu.

Angalia pia hali za kushindwa zinazoendelea baada ya muunganisho: jina linabaki limegawiwa wakati handaki iko chini, na kitovu kinahifadhi njia yake wakati mwenzake hayupo. Hakuna kitu kimoja kinachothibitisha kwamba huduma inafikiwa, ndiyo sababu jaribio la hatua mbili hushinda ping moja kutoka kwa kompyuta mpito.