Weka mipaka ya sheria ya SNAT ya OpenVPN kabla haijavunja nginx
Wateja wanathibitisha lakini hakuna kinachoelekezwa, au tovuti inakufa baada ya VPN kuwaka. Angalia ufikiaji wa tun, kisha weka kikomo cha utafsiri kwa pool na kiolesura kimoja.
Hitilafu mbili huja kila mara kutoka kwa aina moja ya mwenyeji. Katika ya kwanza, wateja wanathibitisha na kisha hawafikii chochote zaidi ya handaki. Katika ya pili, VPN inawaka na tovuti ya seva yenyewe inaacha kujibu, jambo ambalo linatisha zaidi kwa sababu linaonekana kama uharibifu wa pembeni. Kwenye VPS inayotegemea kontena zote mbili kwa kawaida hurudi kwenye orodha hiyo hiyo fupi ya ukaguzi, na mpangilio ni muhimu: kifaa kwanza, utafsiri pili, wigo tatu.
Thibitisha kuwa kontena linaweza kuunda kifaa cha tun
Hakuna kingine kinachojalisha ikiwa kiolesura cha handaki hakiwezi kuwepo. Angalia kuwa /dev/net/tun ipo na uundaji wa kifaa cha majaribio unafanikiwa, kwa sababu watoa huduma wengi huzima tun ndani ya kontena kwa chaguo-msingi. Hakuna kazi ya firewall inayofidia kifaa ambacho hakikuundwa kamwe.
Ikiwa kifaa hakipo, ni mwenyeji au mtoa huduma tu anayeweza kukiwasha. Mpango mwingine mara nyingi ni wa bei nafuu kuliko uzi wa usaidizi ulio wazi unaodumu wiki moja. Thibitisha hili kabla ya kusoma hata mstari mmoja wa kumbukumbu ya OpenVPN. Vinginevyo utatumia jioni kurekebisha sheria ambazo hazitawahi kuona pakiti.
Amua MASQUERADE inafanya nini kwenye kiolesura hiki
Kwenye mashine pepe ya kawaida sheria ya kawaida ya kutoka ni POSTROUTING MASQUERADE kutoka kiolesura kikuu. Katika kontena la OpenVZ kifaa kinachoonekana mara nyingi ni venet0, kiolesura pepe kinachosimamiwa na mwenyeji na si kadi ya mtandao iliyoelekezwa, na MASQUERADE haifanyi kwa mwenendo huo kila wakati kama mafunzo yanavyodhani.
Umbo linalofanya kazi ni utafsiri wa wazi kwenda anwani ambayo wateja tayari wanaifikia, huku usambazaji ukiruhusiwa pande zote mbili. Kubadilisha pool kutoka usanidi wa seva ni muhimu kama kubadilisha anwani. Soma kila mstari kabla ya kuubandika.
iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPTBila sheria za usambazaji utafsiri bado unafanyika na kerneli bado inakataa kusambaza. Mchanganyiko huo huunda hali ya kuchanganya ambapo vihesabu kwenye sheria ya NAT vinapanda wakati mteja hapokei chochote. Mistari miwili ya FORWARD pia lazima isimame kabla ya sheria yoyote pana ya drop katika mnyororo huo. Mpangilio ni sehemu ya usanidi, si maelezo ya utekelezaji.
Weka sheria kwa pool moja na kiolesura kimoja
Dalili ya pili ina sababu tofauti: sheria ya POSTROUTING bila kizuizi cha chanzo wala kizuizi cha kutoka. Sheria kama hiyo huandika upya kila pakiti inayoondoka kwenye mwenyeji.
Huduma zinazotegemea chanzo asili hufanya vibaya wakati huo. Seva ya wavuti nyuma ya proksi ya ndani inaweza kuacha kujibu, na kuizima na kuiwasha tena hakubadilishi chochote kwa sababu sheria ipo bado njiani. Trafiki ambayo mwenyeji hutuma kwa anwani yake ya umma pia imeathirika, ndiyo sababu hitilafu inaweza kuonekana kama tatizo la DNS au cheti badala ya firewall. Sheria iliongezwa karibu bila shaka ili kurekebisha dalili ya kwanza.
Suluhisho ni kupunguza ulinganifu hadi pool ya handaki na kiolesura cha kutoka, kisha kuongeza sheria moja kwa kila pool badala ya kupanua sheria moja kufunika kadhaa.
Fanya sheria ziwe za kudumu na ujue ni nani mwingine anazimiliki
Sheria zilizoongezwa kwa mkono hupotea wakati wa kuwasha upya, kwa hiyo zihifadhi kwa iptables-save au zisimamie kupitia netfilter-persistent mahali palipowekwa. Thibitisha kuwa urejeshaji unaendeshwa kabla OpenVPN kuanza. Kisha washa upya mara moja kwa makusudi badala ya kugundua pengo wakati wa tukio.
Kwenye mwenyeji wa kontena, pia thibitisha kuwa faili ya kudumu iko katika hifadhi ya kontena inayoweza kuandikwa na mtoa huduma habadilishi uchujaji wakati wa kuwasha. Majukwaa mengine husimamia sera nje ya kontena, ambapo sheria za ndani hupuuzwa au hugongana na zile za mwenyeji mwenyewe.
Thibitisha kwa vihesabu na mtiririko mmoja ulionaswa
Kutoka kwa mteja aliyeunganishwa, angalia anwani ya umma ambayo huduma ya nje inaripoti. Ikiwa inalingana na anwani ya seva, utafsiri unafanya kazi; ikiwa haifanyi, pakiti inatoka kwa njia nyingine au haitoki kabisa. Kisha jaribu huduma inayopangishwa kwenye seva na moja kwenye mtandao wa umma, kwa sababu huchukua njia tofauti kupitia seti hiyo hiyo ya sheria.
Kwenye seva, soma vihesabu vya pakiti kwenye sheria za NAT na FORWARD kwa iptables -t nat -L -v -n na uangalie mtiririko mmoja kwenye nasa. Ikiwa anwani ya mteja inaonekana kwenye nasa na hakuna jibu linalofuata, pengo liko kwenye njia ya kurudi au kwenye uchujaji wa mtoa huduma, si kwenye wasifu wa mteja. Linganisha chanzo kilichonaswa na anwani ambayo sheria inatafsiri kwenda, kwa sababu kutokulingana kunamaanisha sheria nyingine ililingana kwanza. Mtiririko mmoja uliozingatiwa huamua zaidi ya ukurasa mmoja wa kusoma usanidi.
Weka pool, anwani iliyotafsiriwa na jina la kiolesura pamoja katika rekodi ya mabadiliko. Sheria iliyo sahihi kwa pool moja hatafsiri vizuri inayofuata.