Kivinjari kinaomba https://203.0.113.10:8443, proksi inakubali muunganisho, na huduma kwenye WireGuard peer haijibu kamwe. Kanuni ya DNAT inafanya kazi yake; sehemu inayoshindikana ni jibu. Fuatilia kifurushi kupitia tafsiri zote mbili na kanuni inayokosekana inakuwa dhahiri. Suluhisho ni tamko moja zaidi la NAT kwenye hook sahihi, si handaki mpya.

Fuatilia ombi moja kutoka mwanzo hadi mwisho

Ombi linafika kwenye kiolesura cha umma cha proksi, likiwa na anwani ya umma ya mteja kama chanzo na anwani ya proksi kama lengo. Ndani ya nat PREROUTING kanuni ya DNAT huandika upya lengo kuwa anwani ya handaki ya peer, 10.90.0.2. Kisha uamuzi wa uelekezaji hutuma kifurushi nje kupitia wg0, na njia ya usambazaji inakamilika.

Kwenye peer kifurushi sasa hubeba anwani ya asili ya umma ya chanzo, kwa sababu hakuna kilichoandika upya. Huduma inakubali muunganisho na kutuma jibu lake kwenye lango lake la chaguo-msingi, ambalo ni ruleta ya nyumbani mbele ya peer. Ruleta hiyo haina hali ya mtiririko ambao haikuwahi kuona na ama inatupa kifurushi au inakitafsiri kwenye anwani yake ya umma, ambayo mteja hatakubali.

Utengano ndio tatizo lote: ombi linapita kwenye proksi, na jibu linajaribu kwenda moja kwa moja. Ufuatiliaji wa miunganisho wa proksi husaidia tu ikiwa jibu linarudi kupitia proksi, na haliwezi kurudi hapo wakati anwani ya chanzo bado inaelekeza kwa mteja wa asili.

Ongeza tafsiri ya kurudi

Andika upya chanzo cha mtiririko unaosambazwa kwenye anwani ya handaki ya proksi kabla ya kuondoka kuelekea peer. Kisha huduma hujibu kwa 10.90.0.1, proksi inaipokea, na ufuatiliaji wa miunganisho hugeuza tafsiri zote mbili kabla kifurushi kurudi kwa mteja.

iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

Kanuni ya POSTROUTING ni nyembamba kwa makusudi: inalingana na lengo lililotafsiriwa na kiolesura cha handaki, kwa hiyo haiandiki upya trafiki isiyohusiana inayotoka kwa bahati kupitia wg0. Kanuni pana ya masquerade pia ingeficha anwani ya mteja, lakini ingefanya hivyo kwa kila mtiririko na ingefanya jedwali la NAT kuwa gumu kukaguliwa.

Weka kanuni mahali handaki ipo

Kanuni zinazorejelea anwani au kiolesura cha handaki lazima zifanye kazi baada ya wg-quick kukisanidi. Kiolesura huundwa kabla ya PreUp, lakini anwani, MTU, DNS na njia hutumika baadaye, na PostUp hufanya kazi pale yote yanapokuwa mahali pake. Weka nyongeza kwenye PostUp na ufutaji kwenye PreDown.

PostUp = iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PostUp = iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1
PreDown = iptables -t nat -D PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PreDown = iptables -t nat -D POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

Ufutaji lazima ulingane na nyongeza token kwa token, ikiwa ni pamoja na ulinganifu wa multiport na kiolesura. Ufutaji unaotofautiana katika ulinganifu mmoja haufuti kitu, na muunganisho unaofuata huongeza nakala ya pili ya kanuni. Baada ya muunganisho kadhaa jedwali lina nakala ambazo ni vigumu kuzihusisha na mstari wa usanidi.

Angalia matokeo kwa iptables -t nat -S baada ya muunganisho upya. Ikiwa kanuni hiyo hiyo inaonekana mara mbili, mstari wa PreDown haulingani na usafishaji unashindikana kimya kimya.

Usambazaji, uchujaji na NAT nyingine

Washa usambazaji wa IPv4 kwa kudumu, kisha ruhusu mtiririko unaosambazwa kwenye jedwali la kichujio. DNAT hutokea kabla ya mnyororo wa FORWARD, kwa hiyo kanuni ya kichujio inalingana na lengo lililotafsiriwa badala ya anwani ya umma. Ikiwa UFW inasimamia firewall, eleza ruhusa kama kanuni ya njia; kanuni ya kawaida ya host haifuniki trafiki inayosambazwa.

Tabaka nyingine mbili za NAT bado zinaweza kuvunja njia hata kanuni za proksi ziwe sahihi. Kwenye muunganisho wa nyumbani anwani ya umma ni ya ruleta, na kufungua bandari kwenye firewall yake si sawa na kuunda ingizo la usambazaji wa bandari linalotuma bandari hiyo kwa proksi. Bandari inayoonekana wazi kutoka nje wakati hakuna kinachojibu mara nyingi haina ramani hiyo hasa.

Kwenye NAT VPS mtoa huduma huweka ramani ya bandari ya umma kwenye anwani ya kibinafsi. Ramani lazima ilingane na bandari unayotangaza, na kutokulingana kunaonekana sawa na handaki iliyovunjika. Thibitisha ramani ya mtoa huduma kabla ya kubadilisha usanidi wa WireGuard.

Thibitisha njia ya kurudi na ukubali gharama

Ungana kutoka mtandao ambao si LAN ya proksi, kisha kagua jozi ya tafsiri wakati muunganisho umefunguliwa:

conntrack -L -p tcp --dport 8080
tcpdump -ni any tcp port 8080

Ingizo la conntrack linapaswa kuonyesha tuple ya asili, tuple iliyotafsiriwa na mwelekeo wa jibu. Ikiwa jibu halipo, peer haitumi kupitia handaki, ambayo kwa kawaida ina maana kwamba kanuni ya SNAT haikutumika au firewall ya peer yenyewe ilitupa mtiririko.

Anzisha upya mara moja ili kuthibitisha kwamba PostUp inatumia kanuni tena, kisha simamisha handaki na uthibitishe kwamba PreDown iliziondoa. Kanuni zilizokufa zinazostahimili kukatika ndizo sababu mabadiliko ya baadaye yanajitokeza kwa namna isiyotabirika.

Mwishowe, kubali gharama ya SNAT. Huduma inaona kila ombi kama linatoka kwa proksi, kwa hiyo kumbukumbu za ufikiaji, mipaka ya kasi kwa mteja na orodha za anwani zilizoruhusiwa hazitofautishi tena watumiaji. Kisa cha hairpin kinahitaji tafsiri yake ya chanzo kwa wateja kwenye LAN ya proksi. Ikiwa peer inahitaji anwani halisi za mteja, mbadala ni njia ya kurudi kwenye mtandao wa mteja, ambayo ni kazi zaidi lakini huhifadhi taarifa.

Makala zinazohusiana