Je, wateja kwenye seva mbili za OpenVPN wanaweza kufikiana?

Kusimamisha seva ya pili ya OpenVPN kunakupa mahali pa pili pa wateja kuunganishwa, na hakuna zaidi. Haiwaweki wateja hao kwenye mtandao wa seva ya kwanza, na chaguo linaloitwa client-to-client hubadilisha tu upitishaji ndani ya mchakato mmoja wa seva. Makundi hayo mawili yanakuwa mtandao mmoja unapopitisha njia kati yao kwa makusudi, ukiwa na mmiliki kwa kila mwelekeo. Kila kitu hapa chini kinachukulia hali ya TUN katika nafasi ya mtumiaji na upitishaji huo wa ndani umezimwa, hivyo kernel inaamua.

Hadithi: orodha moja ya akaunti, mtandao mmoja

Uthibitishaji na ufikivu huchanganywa kwa sababu vyote viwili viko kwenye usanidi wa seva. Mtumiaji anayeweza kuingia kwenye lango lolote kati ya mawili huonekana, kutoka nje, kama mtumiaji kwenye mfumo mmoja wenye milango miwili. Ndani, kila seva hutoa anwani kutoka kundi lake na kuweka njia kwa wateja wanaohudumiwa nayo pekee. Kwa hivyo mteja aliye kwenye lango A anayetuma pakiti kwa mteja aliye kwenye lango B anaomba mahali ambapo seva yake haijasikia kamwe. Pakiti huenda kwenye njia chaguo-msingi ya A, hutoka kwenye handaki, na kufika kwenye firewall ambayo haikuwahi kuombwa kuiruhusu.

Kwa hivyo kuongeza seva ya pili hakuongezi upungufu, ugunduzi au kikoa cha broadcast kinachoshirikiwa. Huongeza mtandao wenye njia unaohitaji mpango, na mpango huo huanza na utoaji wa anwani.

Ipe kila lango kundi lake na anwani ya usafiri

Viwango viwili ambavyo haviwezi kuingiliana na kitu kingine, pamoja na kiungo kidogo cha usafiri kati ya wenyeji, ni mpango mzima wa anwani. Weka usafiri kwenye sehemu ya kibinafsi unayodhibiti, na uandike namba hizo kabla ya seva yoyote kutoa ukodishaji.

Kataa jaribu la kuwapa seva zote mbili kundi moja ili wasifu ufanane. Njia ya kernel haiwezi kusema ni yupi kati ya wenyeji wawili anamiliki anwani yoyote ndani ya kiwango kinachoshirikiwa kwa sasa, kwa hivyo jedwali la njia lingeelekeza kwenye lango moja na mteja anaweza kuwa ameunganishwa na lingine. Majina ya violesura ni taratibu za kienyeji, si hali inayoshirikiwa. Wenyeji wote hapa huita kifaa cha handaki tun0 na kiungo cha usafiri transit0, jambo ambalo ni sawa kwa sababu hakuna pakiti inayobeba majina hayo.

Weka njia pande zote mbili

Kila lango linahitaji njia kuelekea kundi la lingine kupitia anwani ya usafiri, na upitishaji lazima uwe umewashwa ili lolote lifanye kazi kama hop. Hakikisha kwanza jedwali la sasa, kisha ongeza kiingilio na ulifanye lidumu kupitia msimamizi wa mtandao wa mwenyeji badala ya ndoano ya kuunganisha tena.

sysctl net.ipv4.ip_forward
ip route add 10.64.20.0/24 via 172.28.44.2 dev transit0
ip route get 10.64.20.37

Nakili hilo kwenye mwenyeji mwingine ukiwa umebadilisha makundi. Kuongeza njia hiyo hiyo mara kwa mara kutoka kwa script isiyohusiana ndiyo njia ambayo mwenyeji huishia na nakala kadhaa na mabadiliko ya ajabu wakati mwingine mtu anaposoma jedwali. Ikiwa kiungo cha usafiri ni handaki yenyewe, njia huelekeza kwenye topolojia ya handaki hilo na hop lazima idumu baada ya kuunganishwa kwake tena. Anwani ya usafiri inayotoweka kwa sekunde thelathini huchukua njia kati ya makundi, jambo ambalo ni sifa ya muundo inayofaa kutamkwa badala ya kugunduliwa.

Sukuma njia ya mteja bila kujifanya mmiliki

Wateja wanahitaji njia kuelekea kundi la mbali, vinginevyo mfumo wao wa uendeshaji hutuma pakiti kwenye lango chaguo-msingi na handaki haioni kamwe. Usanidi wa seva ni mahali pa asili pa kuileta.

push "route 10.64.20.0 255.255.255.0"

Weka mstari wa nakala kwenye usanidi wa seva nyingine, kisha unganisha tena mteja wa jaribio na usome jedwali lake. Mteja anayepuuza njia zilizosukumwa anahitaji usanidi wake ulioidhinishwa, na njia isiyofika kamwe si udhibiti wa ufikiaji. Usimpe mteja iroute kwa kundi lote la lango lingine. Agizo hilo lipo kwa subnet iliyo nyuma ya mteja mmoja aliyeunganishwa, na kulitumia kufunika njia inayokosekana kati ya malango huzalisha seva inayoamini inamiliki anwani ambazo haiwezi kuzifikia.

Thibitisha ombi moja na ukatae lingine

Chagua operesheni halisi, kwa mfano HTTPS kutoka mteja aliye 10.64.10.21 kwenda huduma iliyo 10.64.20.37, na ruhusu hasa hiyo kwenye wenyeji wote wawili. Kila firewall hukubali ombi upande wake wa kuingia na jibu linalofuatiliwa upande wa kurudi; sera ya huduma yenyewe ya mahali inayokwenda bado inapaswa kuikubali.

iptables -A FORWARD -i tun0 -o transit0 -s 10.64.10.21 -d 10.64.20.37 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i transit0 -o tun0 -d 10.64.10.21 -s 10.64.20.37 -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Ukiwa na njia za pande zote, NAT ya chanzo haihitajiki na hapa inadhuru kwa vitendo: kutafsiri chanzo huficha ni mteja gani aliyetuma ombi na huharibu sera inayotegemea chanzo upande wa mahali panakokwenda. Hakikisha kwamba kanuni iliyopo ya masquerade kwa kutoka mtandaoni haikamati pia njia hii. Kisha jaribu kukataa. Huduma inayopaswa kubaki ya ndani kwenye kundi B lazima ibaki isifikikiwe kutoka kundi A, na jozi za wateja kwenye lango moja zinapaswa kujaribiwa pia, kwa kuwa sera ya upitishaji uliyoibadilisha hivi punde inawahusu pia.

Marekebisho moja zaidi ya mfano wa akili: kiungo cha usafiri hubeba pakiti za ndani zilizofumbuliwa, kwa hivyo ni mpaka wa uaminifu na si dhamana ya kibinafsi. Ikiwa kinavuka mtandao usiodhibiti, linda hop hiyo kwa handaki fiche lililoidhinishwa na upitishe njia kupitia topolojia yake halisi. TLS ya mwanzo hadi mwisho bado inathibitisha programu yenyewe, ndiyo sababu huduma ya ndani inapaswa kuendelea kuitumia.