Ruhusu Mteja Mmoja wa OpenVPN Afikie Mwingine kwa SSH Bila Kufungua Bwawa
Acha client-to-client imezimwa, ruhusu kerneli ikilishe mtiririko mmoja, na acha sehemu nyingine ya bwawa imefungwa. Sheria mbili kwenye seva pamoja na moja kwenye lengwa.
Mteja mmoja anahitaji kufikia huduma ya SSH ya mteja mwingine, na sehemu nyingine ya bwawa inapaswa kubaki imetengwa kama ilivyo sasa. Swichi inayovutia ni client-to-client, ambayo huwasha ufikiaji kati ya wenzao kwa kila mtu kwa wakati mmoja na kupeana uamuzi kwa OpenVPN badala ya kerneli. Jibu jembamba huiacha swichi hiyo imezimwa na kuruhusu uelekezaji na firewall ya seva yenyewe kubeba mtiririko mmoja hasa.
Utaratibu ni muhimu zaidi kuliko maandishi ya sheria, kwa sababu njia mbili huweka pakiti mahali tofauti. Kujua uliyochagua kunaeleza sheria inayoonekana kuwa haifanyi kitu na mwenza anayeunganisha bila hiyo.
Mahali client-to-client huhamisha pakiti
Ikiwa client-to-client imewashwa, seva hupeleka pakiti ya mwenza ndani badala ya kuituma tena nje kupitia kifaa cha handaki, kwa hiyo pakiti haifiki kamwe kwenye njia ya upelekaji ya kerneli. Hilo ni rahisi na pia linamaanisha firewall yako haioni kamwe mtiririko ambao inapaswa kuusimamia. Acha chaguo limezimwa na seva huelekeza pakiti tena nje kupitia kiolesura kilekile, jambo linaloiweka mbele ya netfilter. Kiolesura kilekile kinaingia, kilekile kinatoka, na mnyororo wa FORWARD unapata kura.
Kubadilishana ni wazi: unapata hoja moja ya sera na unachukua kazi ya uelekezaji na upelekaji ambayo njia ya mkato ilikuwa ikifanya kwa ajili yako. Kazi hiyo ni ndogo kwa mtiririko mmoja na inakua kwa kila ubaguzi unaoongeza. Hesabu ubaguzi sasa, kwa sababu seti ya sheria ndiko sera kati ya wenzao inakoishi kwa kweli.
Njia ambayo pakiti ya mwenza huchukua kwa kweli
Fikiri huduma ya Linux Community OpenVPN 2.6, uchakataji wa TUN katika nafasi ya mtumiaji badala ya DCO, topolojia ya subneti, tun0, na bwawa la 10.44.0.0/24 likiwa na mteja A kwenye 10.44.0.21 na mteja B kwenye 10.44.0.37. Kwa topolojia ya subneti, anwani na barakoa ambazo A alipokea tayari zinafunika bwawa, kwa hiyo A hutuma pakiti kwenye kifaa cha handaki bila kuhitaji njia ya ziada iliyosukumwa. Angalia njia halisi kwenye A badala ya kudhani moja.
Kwenye seva pakiti hufika ikiwa imeelekezwa kwa B, ambayo si anwani ya ndani, kwa hiyo hupelekwa. Upelekaji wa IPv4 lazima uwe umewashwa ili jambo hilo litokee kabisa, na utafutaji wa njia lazima uitume pakiti tena nje kupitia tun0. Kwa hiyo firewall huona mtiririko uliopelekwa ukiwa na kiolesura kilekile pande zote mbili, na hilo ndilo undani ambao seti nyingi za sheria huukosa. Hapa hakuna tafsiri ya chanzo inayohitajika, na kuweka anwani ya A ikiwa tupu ndiko kunamruhusu B kutumia sheria yake mwenyewe inayotegemea chanzo.
Sheria mbili kwenye seva, kwa mpangilio huu
Sheria tatu hubeba idhini yote: upelekaji, ubaguzi wa jozi, na utupaji wa kawaida kwa jozi ya handaki. Sheria ya kukubali hutaja jozi na huduma, kwa hiyo idhini huendelea kuishi kwenye bwawa linalokua. Iweke kabla ya katazo lolote la jumla la trafiki ya handaki-kwa-handaki, kwa sababu mechi ya kwanza ndiyo inayoshinda:
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o tun0 -s 10.44.0.21 -d 10.44.0.37 -p tcp --dport 22 -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -j DROPAmri hizo ni za kielelezo na ni za utaratibu wowote ambao mwenyeji wako hutumia kuhifadhi sheria; uingizaji wa wakati wa utekelezaji hupotea kwenye kuwasha kunakofuata. Sheria ya hali ndiyo inayoruhusu majibu ya B na makubaliano ya mkono wa TCP kurudi bila kukubali kwa pili kunakofanana.
Angalia vihesabio baadaye badala ya orodha ya sheria, kwa sababu sheria isiyolingana kamwe inaonekana sawa na inayofanya kazi. Ikiwa vihesabio vinabaki sifuri, pakiti haifuati njia unayofikiri.
Kile B bado inapaswa kuruhusu
B huendesha huduma ya SSH, kwa hiyo B huamua ikiwa kuna kitu kinasikiliza kwenye anwani ya handaki na ikiwa firewall ya mwenyeji wake yenyewe inakubali chanzo. Idhini ya mtandao kwenye seva si idhini kwa akaunti yoyote kwenye B, na uthibitishaji wa ufunguo wa mwenyeji na uthibitishaji wa mtumiaji bado unatumika kama kutoka mahali popote pengine.
Jaribu kwanza hali chanya: muunganisho mpya wa SSH kutoka A kwenda anwani ya handaki ya B, ukikubaliwa na ufunguo wa mwenyeji unaotarajiwa. Kisha jaribu mwenza mwingine au bandari nyingine na uthibitishe kwamba inakataliwa, kwa sababu idhini inayoruhusu kila kitu kwa kimya haiwezi kutofautishwa na inayofanya kazi hadi iwe muhimu. Nusu zote mbili za jaribio hilo ni muhimu, na ya pili ndiyo ambayo watu huiruka.
Andika anwani zilizotolewa, njia halisi kwenye wateja wote wawili na sheria kamili kwenye seva na kwenye B. Ping iliyofanikiwa kwenda kwenye lango au bandari iliyofunguliwa kwenye seva haithibitishi lolote la haya, kwa kuwa yote mawili yanaweza kuwa kweli wakati upelekaji kati ya wenzao bado umezuiwa. Andika nambari hizo wakati handaki iko juu, kwa sababu anwani ambayo mteja hupokea baada ya kuunganisha tena inaweza kuwa nyingine.