Mahali NAT ya VPN inapokwenda katika before.rules ya UFW na jinsi ya kuipima

Kanuni ya NAT inayofanya kazi inapochapwa kwenye shell hushindwa inapobandikwa kwenye before.rules, kwa sababu faili hiyo si script. Ni hati ya muundo wa urejeshaji yenye sehemu za jedwali, matamko ya mnyororo na alama ya COMMIT kwa kila jedwali. Mstari mahali pabaya ama husitisha urejeshaji wote au hutupa kimya kanuni ulizodhani zipo. Mwongozo ulio hapa chini unaweka kipande mahali ambapo mfumo unakitarajia na huthibitisha matokeo kabla ya upakiaji upya unaofuata.

Amri ya shell si faili ya urejeshaji

Mstari unaoanza na iptables -t nat ni maagizo kwa binary ya iptables, ilhali faili ambayo UFW husoma ni maelezo ya seti kamili ya kanuni. Tofauti si ya mapambo: muundo wa urejeshaji lazima ujue uko kwenye jedwali gani, ni minyororo ipi iliyopo na jedwali linaishia wapi. Amri iliyobandikwa kwenye hati hiyo ama ni kosa la sintaksia au, mbaya zaidi, kanuni iliyounganishwa na jedwali lisilo sahihi. Mfumo hupakia faili hizi kupitia zana za urejeshaji kwa sababu ni za kutangaza na si za mfuatano.

Hati pia hupakiwa kwa ujumla wake, kwa hiyo sehemu moja yenye hitilafu inaweza kusitisha utumiaji wa sehemu iliyobaki ya faili. Kwa hiyo kosa dogo katika kipande cha NAT hushusha pia kanuni za kuchuja, na hivyo mabadiliko ya firewall huwa usumbufu.

Weka kipande ndani ya sehemu iliyopo ya jedwali

Kipande cha NAT kina umbo, na umbo ni muhimu zaidi kuliko maandishi ya kanuni ndani yake. Kichwa cha jedwali hufungua sehemu, matamko ya mnyororo huweka vihesabu, kanuni hufuata, na COMMIT hufunga sehemu.

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT

Bwawa na kiolesura vilivyo juu ni nafasi za thamani zako mwenyewe; muundo ni sehemu inayofaa kunakiliwa. Ikiwa faili tayari ina sehemu ya *nat, ongeza kanuni ndani ya sehemu hiyo badala ya kufungua ya pili, kwa sababu muundo unatarajia COMMIT moja kwa kila jedwali na sehemu mbili kwa jedwali moja ni ukarabati unaosubiri kutokea. Weka matamko ya mnyororo wa usambazaji bila kubadilika, ikiwa ni pamoja na yale ambayo mtoa huduma aliongeza kwa muunganisho wake mwenyewe. Mwongozo wa mfumo wa UFW unaandika faili za before, user na after pamoja na sharti la COMMIT inayolingana.

Ikiwa faili itaonekana kuwa tupu, usiijaze kutoka kwenye mafunzo. Thibitisha ni kifurushi kipi kinachomiliki na sera inayoendelea kwa kweli ni ipi, kwa sababu faili tupu ya kudumu haithibitishi kuwa kernel haina kanuni, na seti ya kanuni iliyopakiwa haithibitishi kuwa upakiaji upya ujao utakuwa na faili kamili ya kusoma. Kwanza rejesha msingi unaotumika, kisha tumia tena mabadiliko ya tovuti juu yake.

Jaribu mteule bila kuitumia

Zana ya urejeshaji inaweza kuchanganua na kujenga seti ya kanuni bila kuitumia, na hii ni jaribio la bei nafuu zaidi linalopatikana. Iendeshe dhidi ya nakala iliyolindwa badala ya faili inayoendelea, na soma maandishi ya kosa badala ya hali ya kutoka pekee. Kushindwa kwa uchanganuzi hutaja mstari na kwa kawaida jedwali, ambayo ni zaidi ya upakiaji upya ulioshindwa utakuambia.

sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"

Kupita ukaguzi huo kunathibitisha kuwa hati inachanganuliwa na hakuna kingine. Haithibitishi kuwa mteule bado ana kila mnyororo ambao UFW inautegemea, kwamba unaruhusu vyanzo ulivyokusudia pekee, au kwamba usimamizi wa mbali unabaki kufikiwa. Hizi ni tathmini tofauti, na ya mwisho inastahili kipindi cha pili kinachofunguliwa kabla ya kuanza.

Chagua zana inayolingana na backend iliyosakinishwa na familia ya anwani. Mwenyeji anayeendesha backend ya nft kupitia tabaka la uoanifu anahitaji amri inayolingana, na kanuni za IPv6 zinaishi katika faili tofauti kabisa.

Tenganisha uelekezaji, NAT na sera ya ufikiaji

Tafsiri ya chanzo hutatua tatizo la anwani na haitoi chochote. Uelekezaji ni ruhusa tofauti inayodhibitiwa na sysctl na jedwali la kuchuja, na ndiyo ambayo watu husahau wakati handaki inaelekeza lakini haipitishi trafiki. Sera ya ufikiaji ni uamuzi wa tatu kuhusu vyanzo vipi vinaweza kufikia huduma zipi, na hakuna kanuni ya NAT inayoeleza hilo. Kutenganisha hivi vitatu ndiko kunafanya kushindwa kuweza kutambuliwa badala ya dalili moja isiyoeleweka.

sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD

Soma matokeo hayo matatu pamoja, si moja baada ya nyingine. Kanuni ya masquerade yenye uelekezaji umezimwa hutoa mteja anayeunganishwa na hafiki popote, ambayo kwa upande wa mteja inaonekana kama hitilafu ya uelekezaji na kuwapeleka watu kwenye faili isiyo sahihi. Jedwali la kuchuja pia ni mahali ambapo accept pana mno hujificha, kwa hiyo angalia sera yake ya chaguo-msingi ukiwa hapo.

Thibitisha upakiaji upya, kukataliwa na kupoteza VPN

Uchunguzi matatu huunda jaribio kamili la kukubali: upakiaji upya unafanikiwa, operesheni ya mteja iliyoruhusiwa inafanya kazi, na ombi ambalo linapaswa kukataliwa kwa kweli linakataliwa. La tatu ndilo linalorukwa, na ndilo ushahidi pekee kwamba sera inafanya kitu chochote.

sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

Kisha jaribu kushindwa ulikokusudia. Angusha handaki na uangalie mwenyeji anafanya nini, kwa sababu sera inayofanya kazi tu wakati VPN iko juu ni sera yenye utegemezi usiotajwa. Kisha pakia upya mara moja zaidi ili kuthibitisha kuwa faili, na si hali ya uendeshaji iliyobaki, ndiyo inayotoa matokeo yanayofanya kazi.

NAT ya IPv4 haisemi chochote kuhusu IPv6, kwa hiyo taja ufikiaji uliokusudiwa kwa familia zote mbili katika dokezo lile lile la kanuni. Lengo ni sera thabiti inayosimamiwa, na kipande kilichochanganuliwa kwa bahati si ushahidi wake.