Elekeza nje ya VPN huduma moja tu ya wavuti ya ndani, kwa bandari

Huduma moja ya mwenyeji lazima ijibu intaneti kupitia kiungo cha juu cha kimwili huku kila kitu kingine kwenye mashine kikiendelea kutumia handaki. Masharti matatu yanaamua kama uelekezaji unaotegemea sera unaweza kubeba mzigo huo, na kila moja ni rahisi kukagua kabla ya kuandika kanuni. Huduma lazima iishie kwenye mwenyeji huyu na si nyuma ya DNAT au bandari iliyopelekwa mbele, kanuni za VPN zenyewe lazima zikubali ubaguzi, na lazima ulinganishe jibu badala ya ombi. Ikishindikana moja kati ya matatu, amri zilizo hapa chini hupakiwa bila hitilafu lakini hazifanyi chochote cha manufaa.

Kagua masharti matatu kabla ya kuandika kanuni

Kontena linalochapisha bandari kupitia DNAT, au seva iliyo nyuma ya upelekaji wa bandari, huzalisha pakiti ambazo hazitoki kwenye mwenyeji huyu. Pakiti hizo hupelekwa mbele, kwa hiyo kanuni inayotegemea pembejeo la ndani la mwenyeji hailioni kamwe na trafiki inaendelea kuchukua njia ya chaguo-msingi. Thibitisha huduma inaendeshwa wapi kwa kweli kabla ya kuendelea, kwa sababu hili ndilo sharti ambalo watu hukosea zaidi.

Sharti la pili ni sera na si ufundi. Njia yoyote inayokwepa handaki ni ubaguzi kwa madhumuni ya handaki, na kwenye mwenyeji unaosimamiwa uamuzi huo ni wa anayemiliki sera, si wa anayechunguza muda wa kumaliza.

Linganisha jibu, si bandari ya mwisho ya mteja

Jibu kutoka kwa seva inayosikiliza TCP 443 huondoka kwenye mwenyeji likiwa na bandari chanzo 443. Kivinjari kwenye mwenyeji huyo huyo kinapounganisha na tovuti ya HTTPS ya mbali hutuma bandari chanzo ya muda na bandari ya mwisho 443. Zote mbili ni trafiki ya bandari 443 na ni moja tu inapaswa kuchukua jedwali la WAN, ndiyo sababu ulinganishaji wa bandari ya mwisho ungekamata nusu isiyo sahihi.

Mwelekeo wa jibu ndicho unachoweza kutofautisha. Linganisha bandari chanzo, weka kanuni kwa pakiti zilizozalishwa ndani tu, na kanuni hiyo inashughulikia majibu ya huduma yenyewe bila kugusa maombi ya kivinjari.

Jenga jedwali kamili la kurudi kabla kanuni haijaelekeza kwalo

Jedwali tupu humaanisha hakuna njia, ambayo inaonekana kama huduma iliyovunjika badala ya sera iliyovunjika. Ijaze kwanza, kwa namba ya jedwali na kipaumbele ambavyo hakuna kitu kingine kwenye mwenyeji kinachodai:

ip -4 route add table 100 192.0.2.0/24 dev eth0
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 iif lo ipproto tcp sport 443 lookup 100

Soma namba kutoka kwa mwenyeji hai badala ya kuzinakili. ip -4 rule show hukuambia ni vipaumbele gani vimechukuliwa, na kuongeza kanuni kwenye kipaumbele kilichopo tayari hubadilisha kimya mpangilio wa kanuni mbili ambazo kila moja peke yake zinaonekana sawa.

Hapa kazi halisi huifanya vichaguzi viwili. iif lo ni jinsi kerneli inavyoripoti pakiti ambazo mwenyeji mwenyewe amezalisha, kwa hiyo kanuni haiwezi kukamata kwa bahati mbaya trafiki iliyopelekwa mbele inayokuja kutoka nje. ipproto tcp sport 443 huiweka nyembamba hadi usafirishaji mmoja na bandari moja, ambayo ni finyu kama mahitaji yanavyoruhusu. Ondoa kichaguzi cha itifaki na kanuni itakamata pia UDP 443, ambayo ni huduma nyingine yenye tabia nyingine.

Weka majibu ya faragha ndani ya handaki

Ikiwa msikilizaji huyo huyo pia anajibu wateja wa upande wa faragha, njia ya chaguo-msingi ya WAN inayokamata kila kitu kwenye jedwali 100 itajaribu kurudisha majibu hayo kupitia kiungo cha juu. Ongeza viambishi vya faragha ambavyo havipaswi kufuata chaguo-msingi la WAN, au viache vianguke kwenye kanuni inayofuata ya sera:

ip -4 route add table 100 throw 10.90.0.0/24

Njia ya throw inamaliza utafutaji kwenye jedwali hili na kurudisha pakiti kwenye orodha ya kanuni, kwa hiyo sera ya VPN inayofuata inapata nafasi yake. Yenyewe haielekezi chochote kwenye handaki, na ikiwa hakuna kanuni ya baadaye yenye njia inayolingana pakiti bado itashindikana; thibitisha sera inayofuata badala ya kudhani throw ni marekebisho.

Uchujaji wa njia ya kurudi na kanuni za ukuta wa moto wa mwenyeji bado zinatumika kwa ombi linaloingia. Angalia maamuzi yao halisi kabla ya kulegeza uthibitishaji, kwa sababu ubaguzi wa uelekezaji haufanyi rp_filter ikubali njia ya kurudi ambayo inaiona haiwezekani.

Jaribu TCP, kisha QUIC, kisha kuwasha upya

Fungua muunganisho mmoja kutoka kwa mteja wa nje aliyeruhusiwa na mmoja kutoka upande wa faragha, kisha chunguza utafutaji wa jibu kwa anwani na bandari halisi. Ikiwa jibu la nje linachukua jedwali 100 na la faragha halichukui, sera inafanya ulichoomba.

HTTP/3 huhudumiwa kupitia UDP na haitalinganishwa na kanuni ya TCP, kwa hiyo msikilizaji wa QUIC anahitaji kichaguzi chake, vinginevyo ataendelea kutumia handaki wakati HTTPS inafanya kazi. Hifadhi kanuni unazoamua kwenye sehemu inayomiliki kiolesura, na uzithibitishe baada ya kuunganisha tena au kuhuisha DHCP. Msimamizi mshindani anapoondoa njia ya wakati wa utekelezaji baada ya kuwasha upya, hiyo ni tatizo la umiliki linalopaswa kurekebishwa kwenye chanzo, si sababu ya kuongeza kanuni pana zaidi za NAT juu yake.