Bakit ang pampublikong Linux service mo ay sumasagot sa VPN

Wala sa socket ang nakakaalala kung aling interface ang nagdala ng kahilingan, kaya ang default na ruta ng full-tunnel na VPN ay maaaring mahuli ang sagot na dapat sa WAN. Hindi binabalewala ng serbisyo ang papasok na interface; itinutuon ng Linux ang sagot na ginawa nang lokal ayon sa destinasyon at patakaran sa pinagmulan. Ang panuntunang nakabatay sa pinagmulan ay maaaring magpadala lamang ng mga sagot ng serbisyo sa kumpletong talahanayan ng WAN, at iiwan ang karaniwang labasan sa tunnel. Nananatiling bukas ang port habang lumalabas ang sagot sa maling landas, at iyon ang dahilan kung bakit mukhang isang panig ang sintomas.

Ang maling akala: sinusundan ng mga sagot ang interface kung saan sila dumating

Mukhang lohikal na ang packet na dumarating sa eth0 ay dapat lumabas sa eth0. Maaaring isulat nang ganoon ang mga stateless na filter ng packet, at ipinapakita ng tcpdump sa papasok na bahagi ang kahilingan mismo sa inaasahang lugar. Hindi ganoon gumagana ang routing para sa trapikong nililikha ng host mismo.

Kapag tinanggap ng serbisyo ang koneksyon, ang sagot nito ay isang bagong packet na ginawa nang lokal. Sinusuri ng kernel ang mga panuntunan sa routing para sa destinasyon at pinagmulan ng sagot, at ang default na ruta ng VPN ay isang ganap na wastong sagot. Wala sa socket ang nakakaalala kung aling interface ang nagdala ng kahilingan.

Kaya mukhang isang panig ang sintomas: dumarating ang mga kahilingan, naglalaho ang mga sagot. Kaya rin walang nababago ang pagdaragdag ng panuntunan sa firewall para sa papasok na port. Hindi hinaharangan ang packet sa papasok na landas; itinutuon ito sa ibang lugar sa palabas na landas. Subaybayan ang sagot gamit ang paghahanap na itinakda ng pinagmulan at makikita ang lihis.

Ano talaga ang itinutuon ng kernel: ang address ng pinagmulan

Ang hawakan na kailangan mo ay ang lokal na address na ginagamit ng serbisyo para sa mga sagot. Sa host na may ilustratibong address ng eth0 na 192.0.2.10/24 at gateway na 192.0.2.1, ang address na iyon ay naroroon sa interface. Sa VM sa cloud, ang pampublikong address ay maaaring isinalin sa itaas at wala sa bisita, kaya gamitin ang address na talagang taglay ng host.

Suriin ang kasalukuyang kalagayan bago magreserba ng numero ng talahanayan o prayoridad ng panuntunan. Maaaring tabunan ng mga umiiral na panuntunan sa patakaran ang bago, at ang lumang talahanayan na may parehong numero ay maaaring may dalang mga rutang walang kaugnayan:

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

Pagkatapos pumili ng talahanayan ayon sa pinagmulan. Tumutugma ang panuntunan sa mga sagot na may dalang 192.0.2.10 na, eksaktong ang trapikong natapos nang lokal na gusto mong ibukod. Hindi tumutugma ang trapikong ipinasa at ang mga packet mula sa iba pang lokal na address.

Bumuo ng kumpletong talahanayan ng pagbabalik, hindi kalahating default

Hindi sapat ang talahanayang may default na ruta lamang. Kailangan pa ring lutasin ng kernel ang gateway, at kailangan ng paglutas na iyon ang konektadong prefix sa parehong talahanayan. Ang talahanayang kulang sa prefix na iyon ay nabibigo sa paglutas ng gateway kahit mukhang tama ang default na ruta nito. Idagdag ang dalawa, pagkatapos ituro ang panuntunan sa pinagmulan sa talahanayan:

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

Gamitin ang tunay na prefix at gateway sa halip na kopyahin ang halimbawa. Ang interface sa cloud na na-configure bilang /32 na may on-link na gateway ay nangangailangan ng ibang konektadong ruta, at ang talahanayang itinayo mula sa maling prefix ay nabibigo sa unang hop. Isinasaad ng attribute na src ang ginustong pinagmulan para sa rutang iyon; hindi nito pinapalitan ang panuntunan sa pinagmulan.

Mahalaga rin ang pagkakasunod-sunod. Ang malawak na panuntunan na may mas mababang numero ng prayoridad ay sinusuri muna, kaya dapat maabot ang panuntunan sa pinagmulan bago ang anumang panuntunang magbabalik ng trapikong ito sa pangunahing talahanayan. Suriin ang mga prayoridad gamit ang ip rule show pagkatapos idagdag ito, hindi lamang sa pag-boot.

I-verify gamit ang paghahanap na itinakda ng pinagmulan

Hilingin sa kernel na i-routing ang test na destinasyon mula sa address ng serbisyo. Dapat banggitin ng sagot ang eth0 at ang WAN gateway, hindi ang tunnel:

ip -4 route get 198.51.100.25 from 192.0.2.10

Pagkatapos ay gumawa ng bagong awtorisadong koneksyon at obserbahan ang dalawang direksyon. Ang paghahanap na pumipili ng tamang talahanayan habang nabibigo pa rin ang live na koneksyon ay tumuturo sa reverse-path filtering o panuntunan sa firewall, hindi sa talahanayan. Suriin ang mga kontrol na iyon bago i-disable ang anuman nang pandaigdigan.

Ilagay ang mga huling ruta at ang panuntunan sa ilalim ng tagapamahala ng network na nagmamay-ari ng interface. Binabago ng mga pagbabago sa address, pag-renew ng DHCP at muling pagkonekta ng VPN ang lahat ng kalagayan ng kernel, at ang panuntunang idinagdag sa kamay ay nawawala o tumuturo sa lumang gateway pagkatapos ng susunod na pangyayari.

Saan humihinto ang pagbubukod na ito

Ibinubukod ng panuntunan ang trapikong natapos nang lokal mula sa isang address ng pinagmulan. Hindi nito saklaw ang mga port na inilathala ng Docker, DNAT o mga serbisyong ipinasa sa host, dahil ang mga packet na iyon ay itinutuon bilang ipinasang trapiko at hindi kailanman nagdadala ng lokal na pinagmulan ng host sa parehong paraan. Ang ganitong mga disenyo ay karaniwang nangangailangan ng markang inilagay sa ingress at panuntunang tumutugma sa marka.

Hindi rin nito ginagawang lumitaw ang pampublikong address ng host sa interface. Kapag pagmamay-ari ng upstream NAT ang address na iyon, kailangan pa ring lumabas ng sagot sa landas na inaasahan ng NAT na iyon, kaya dapat ipakita ng WAN table ang orihinal na gateway at prefix sa halip na hulaang pampublikong hanay.

Panatilihing nakadokumento ang pagbubukod kasama ang numero ng talahanayan, prayoridad ng panuntunan at eksaktong address ng pinagmulan. Ang susunod na pagbabago sa VPN o sa interface ay maaaring tahimik na makasira nito, at ang tala na nagbabanggit ng tatlong halaga ay mas mabilis suriin kaysa muling tuklasin ang sintomas mula sa ulat ng customer.

Kung sumasagot pa rin ang serbisyo sa maling landas pagkatapos ng matagumpay na paghahanap na itinakda ng pinagmulan, ihambing ang address ng pinagmulan ng live na socket sa nasa panuntunan. Ang serbisyong nakatali sa wildcard na address ay maaaring pumili ng ibang pinagmulan kaysa sa address na sinubukan mo, at ang pagkakaibang iyon ang natitirang puwang.