Je, unapaswa kutumia SNAT kwenye usambazaji wa bandari kwenye subnet ya VPN?

Kusambaza bandari kwa mwenyeji aliye nyuma ya mteja wa VPN wa kipanga njia yenyewe hushindwa kwa namna inayofanana na tatizo la ukuta wa moto, kwa sababu ombi linafika waziwazi. Huduma hurekodi muunganisho, mteja anasubiri, na hakuna kinachorudi. Utafsiri wa lengwa ulifanya kazi yake; pakiti ya kurudi ndiyo sehemu iliyopotea. Sheria moja teule ya NAT chanzo kwenye kipanga njia hutatua hili, na sehemu ya kuvutia ni kuamua jinsi sheria hiyo inaweza kuwa nyembamba.

Kwa nini jibu huchukua njia nyingine

Usambazaji wa bandari huandika upya pakiti inakoelekea, kamwe haipo ilikotoka. Anwani ya mteja wa intaneti hubaki kwenye sehemu ya chanzo katika njia yote ya handaki, kwa hiyo huduma ya mbali humwona mgeni na hujibu kwa njia pekee anayoijua: kupitia lango lake la kawaida. Lango hilo ni kituo cha VPN upande wa mbali, ambacho hakina njia ya kurudi kwenye anwani yoyote ya umma.

Tazama nakala kwenye kiolesura cha handaki na utofauti ni dhahiri: pakiti za ombi zinatoka, hakuna kinachoingia. Mnyororo wa usambazaji uliruhusu mtiririko na handaki uliubeba, kwa hiyo kuangushwa hutokea baada ya mwenyeji wa mbali kuwa amechagua njia ya kurudi.

Sheria ya chanzo nyembamba vya kutosha kuaminiwa

Fanya kipanga njia kuwa chanzo ambacho mwenyeji wa mbali hujibu. Katika mpangilio huu anwani ya WAN ni 203.0.113.24, LAN ni 192.168.88.0/24, anwani ya handaki ya kipanga njia ni 172.20.5.1, na huduma hujibu kwenye 172.20.5.40:8443. Sheria iliyo hapa chini inalingana na pakiti baada ya utafsiri wa lengwa, ndiyo sababu inataja anwani iliyotafsiriwa badala ya ile ya umma. Hakuna kitu ndani yake kinachotegemea anwani ya mteja, na hiyo ndiyo hoja hasa.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

Kila ulinganifu katika mstari huo upo ili kuweka uandikaji upya kuwa wa ndani kwa huduma moja kwenye handaki moja. Ondoa kiolesura au bandari na utaandika upya trafiki nyingi kuliko tatizo linavyohitaji, na hivyo ndivyo marekebisho lengwa yanavyogeuka kuwa kitendawili kwa mtu anayefuata.

Ni lini uficho wa jumla ndiyo chaguo la uaminifu

Ikiwa kipanga njia kinasambaza huduma nyingi kwenye subnet moja ya VPN, sheria ya kila huduma inakuwa orodha ambayo hakuna anayeitunza. Kuficha kila kitu kinachotoka kwenye kiolesura cha handaki ni rahisi na kunatabirika, kwa gharama ya kumficha mteja wa awali kutoka kwa kila mwenyeji upande wa mbali. Chagua hiyo wakati kumbukumbu za huko hazitumiki kwa uhusiano; shikilia sheria nyembamba zinapotumika.

Chaguo zote mbili pia hushindwa kwa namna tofauti. Sheria nyembamba iliyokosekana huvunja huduma moja; uficho mpana unaolingana na mengi mno unaweza kuandika upya kwa utulivu trafiki iliyokuwa ikifanya kazi, ikiwemo miunganisho ya kutoka ya kipanga njia yenyewe.

Angalia vihesabu kabla ya kuchapisha

Sheria ambazo hazilingani kamwe huonekana sawa na sheria zinazofanya kazi hadi utakapohesabu pakiti. Soma tena jedwali ukiwa na vihesabu vya baiti kabla mteja yeyote kuunganisha, kisha unganisha kutoka mtandao ambao si LAN na usome tena. Usomaji mara mbili ndio unaobadilisha dhana kuwa ukweli. Chapisha usambazaji baada ya wa pili kusogea pekee.

iptables -t nat -L POSTROUTING -v -n --line-numbers

Kihesabu cha sifuri kwenye sheria ya chanzo baada ya muunganisho halisi kinamaanisha ulinganifu si sahihi, kwa kawaida kwa sababu lengwa au bandari hailingani na pakiti baada ya utafsiri. Ikiwa kihesabu kinapanda lakini mteja bado anapitwa na muda, njia ya kurudi imerekebishwa na kitu kingine kinadondosha jibu, kwa hiyo angalia sera ya usambazaji upande wa mbali baadaye. Ufikiaji wa hairpin kutoka ndani ya LAN ni tatizo tofauti na unahitaji sheria yake mwenyewe, si toleo pana la hili.