Kwa nini huduma yako ya umma ya Linux hujibu kupitia VPN

Hakuna kitu kwenye soketi kinachokumbuka ni kiolesura kipi kilichobeba ombi, kwa hiyo njia chaguo-msingi ya VPN ya handaki kamili inaweza kunasa jibu ambalo ni la WAN. Huduma haipuuzi kiolesura cha kuingia; Linux huelekeza jibu lililozalishwa ndani kwa misingi ya lengwa na sera ya chanzo. Kanuni inayotegemea chanzo inaweza badala yake kutuma majibu ya huduma pekee kupitia jedwali kamili la WAN, na kuacha utokeaji wa kawaida kwenye handaki. Bandari hubaki wazi wakati jibu linatoka kwa njia isiyo sahihi, na hiyo ndiyo sababu dalili huonekana upande mmoja.

Dhana potofu: majibu hufuata kiolesura yalikotokea

Inaonekana kuwa jambo la busara kwamba pakiti inayofika kwenye eth0 inapaswa kutoka kwenye eth0. Vichujio vya pakiti visivyo na hali vinaweza kuandikwa hivyo, na tcpdump upande wa kuingia huonyesha ombi mahali panapotarajiwa. Uelekezaji haufanyi kazi hivyo kwa trafiki ambayo mwenyeji mwenyewe huizalisha.

Mara huduma inapokubali muunganisho, jibu lake ni pakiti mpya iliyozalishwa ndani. Kiini hushauriana na kanuni za uelekezaji kwa lengwa na chanzo cha jibu, na njia chaguo-msingi ya VPN ni jibu halali kabisa. Hakuna kitu kwenye soketi kinachokumbuka ni kiolesura kipi kilichobeba ombi.

Ndiyo sababu dalili huonekana upande mmoja: maombi huja, majibu hupotea. Ndiyo sababu pia kuongeza kanuni ya firewall kwa bandari ya kuingia hakubadilishi chochote. Pakiti haizuiwi kwenye njia ya kuingia; inaelekezwa mahali pengine kwenye njia ya kutoka. Fuatilia jibu kwa utafutaji uliobainishwa kwa chanzo na mchepuko utaonekana.

Kile kiini huelekeza kwa kweli: anwani ya chanzo

Kipini unachohitaji ni anwani ya ndani ambayo huduma hutumia kwa majibu. Kwenye mwenyeji mwenye anwani ya mfano ya eth0 192.0.2.10/24 na lango 192.0.2.1, anwani hiyo ipo kwenye kiolesura. Kwenye VM ya wingu anwani ya umma inaweza kuwa imetafsiriwa juu na kukosekana kwa mgeni, kwa hiyo tumia anwani ambayo mwenyeji anayo kweli.

Kagua hali ya sasa kabla ya kuhifadhi nambari ya jedwali au kipaumbele cha kanuni. Kanuni zilizopo za sera zinaweza kufunika mpya, na jedwali la zamani lenye nambari hiyo hiyo linaweza kuwa tayari limebeba njia zisizohusiana:

ip -4 addr show dev eth0
ip -4 rule show
ip -4 route show table all

Kisha chagua jedwali kwa misingi ya chanzo. Kanuni inalingana na majibu ambayo tayari yanabeba 192.0.2.10, yaani trafiki iliyokamilika ndani unayotaka kuiondoa. Trafiki inayopitishwa na pakiti kutoka anwani nyingine za ndani hazilingani.

Jenga jedwali kamili la kurudi, si nusu ya njia chaguo-msingi

Jedwali lenye njia chaguo-msingi pekee halitoshi. Kiini bado kinapaswa kutatua lango, na utatuzi huo unahitaji kiambishi awali kilichounganishwa kwenye jedwali hilo hilo. Jedwali lisilo na kiambishi hicho hushindwa katika utatuzi wa lango hata wakati njia yake chaguo-msingi inaonekana sahihi. Ongeza vyote viwili, kisha uelekeze kanuni ya chanzo kwenye jedwali:

ip -4 route add table 100 192.0.2.0/24 dev eth0 src 192.0.2.10
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 from 192.0.2.10/32 lookup 100

Tumia kiambishi awali na lango halisi badala ya kunakili mfano. Kiolesura cha wingu kilichosanidiwa kama /32 na lango la on-link kinahitaji njia nyingine iliyounganishwa, na jedwali lililojengwa kutoka kiambishi awali kibaya hushindwa kwenye hatua ya kwanza. Sifa ya src hueleza chanzo kinachopendelewa kwa njia hiyo; haichukui nafasi ya kanuni ya chanzo.

Mpangilio pia ni muhimu. Kanuni pana yenye nambari ndogo ya kipaumbele hutathminiwa kwanza, kwa hiyo kanuni ya chanzo lazima ifikiwe kabla ya kanuni yoyote ambayo ingerudisha trafiki hii kwenye jedwali kuu. Kagua vipaumbele kwa ip rule show baada ya kuiongeza, si wakati wa kuwasha tu.

Thibitisha kwa utafutaji uliobainishwa kwa chanzo

Omba kiini kuelekeza lengwa la jaribio kutoka anwani ya huduma. Jibu linapaswa kutaja eth0 na lango la WAN, si handaki:

ip -4 route get 198.51.100.25 from 192.0.2.10

Kisha tengeneza muunganisho mpya ulioidhinishwa na uangalie pande zote mbili. Utafutaji unaochagua jedwali sahihi wakati muunganisho halisi bado unashindwa unaonyesha uchujaji wa njia ya kurudi au kanuni ya firewall, si jedwali. Kagua vidhibiti hivyo kabla ya kuzima kitu chochote kimataifa.

Weka njia za mwisho na kanuni chini ya msimamizi wa mtandao anayemiliki kiolesura. Mabadiliko ya anwani, uhuishaji wa DHCP na kuunganishwa upya kwa VPN vyote huandika upya hali ya kiini, na kanuni iliyoongezwa kwa mkono hupotea au huelekeza kwenye lango lililopitwa na wakati baada ya tukio lifuatalo.

Mahali ambapo msamaha huu unaishia

Kanuni inasamehe trafiki iliyokamilika ndani kutoka anwani moja ya chanzo. Haijumuishi bandari zilizochapishwa na Docker, DNAT au huduma zinazopitishwa kupitia mwenyeji, kwa sababu pakiti hizo huelekezwa kama trafiki inayopitishwa na kamwe hazibeba chanzo cha ndani cha mwenyeji kwa namna hiyo hiyo. Miundo kama hiyo kwa kawaida huhitaji alama iliyowekwa kwenye ingizo na kanuni inayolingana na alama hiyo.

Pia haifanyi anwani ya umma ya mwenyeji kuonekana kwenye kiolesura. Wakati NAT ya juu inamiliki anwani hiyo, jibu bado linapaswa kutoka kwa njia ambayo NAT hiyo inatarajia, ndiyo sababu jedwali la WAN linapaswa kuakisi lango na kiambishi awali vya awali badala ya masafa ya umma yaliyokisiwa.

Hifadhi msamaha ukiwa umeandikwa pamoja na nambari ya jedwali, kipaumbele cha kanuni na anwani kamili ya chanzo. Mabadiliko yajayo kwenye VPN au kiolesura yanaweza kuivunja kwa utulivu, na kidokezo kinachotaja thamani tatu hukaguliwa haraka kuliko kugundua tena dalili kutoka ripoti ya mteja.

Ikiwa huduma bado inajibu kwa njia isiyo sahihi baada ya utafutaji uliobainishwa kwa chanzo kufaulu, linganisha anwani ya chanzo ya soketi hai na ile iliyo kwenye kanuni. Huduma iliyofungwa kwenye anwani ya wildcard inaweza kuchagua chanzo tofauti na anwani uliyojaribu, na tofauti hiyo ndiyo pengo lililobaki.