Kial via publika Linux-servo respondas tra la VPN anstataŭe

Nenio en la ingo memoras, kiun interfacon portis la peton, do plentunela VPN-defaŭlto povas kapti respondon, kiu apartenas al la WAN. La servo ne ignoras la envenan interfacon; Linux enkursigas loke generitan respondon laŭ la celo kaj la fonta politiko. Fonta regulo povas anstataŭe sendi nur la respondojn de la servo tra kompleta WAN-tabelo, lasante la ordinaran eliron sur la tunelo. La pordo restas malfermita dum la respondo eliras laŭ la malĝusta vojo, kaj tial la simptomo ŝajnas unuflanka.

La miskompreno: respondoj sekvas la interfacon, per kiu ili alvenis

Ŝajnas logike, ke paketo alvenanta sur eth0 foriru sur eth0. Senstatuj pakitaj filtriloj povas esti skribitaj tiel, kaj tcpdump ĉe la envena flanko montras la peton ĝuste tie, kie oni atendas. Enkursigado ne funkcias tiel por trafiko, kiun la gastiganto mem kreas.

Post kiam la servo akceptas la konekton, ĝia respondo estas nova loke generita paketo. La kerno konsultas la enkursigajn regulojn por la celo kaj fonto de la respondo, kaj la defaŭlta vojo de la VPN estas tute valida respondo. Nenio en la ingo memoras, kiun interfacon portis la peton.

Tial la simptomo ŝajnas unuflanka: petoj alvenas, respondoj malaperas. Tial ankaŭ aldoni fajroŝirma regulon por la envena pordo ŝanĝas nenion. La paketo ne estas blokata survoje enen; ĝi estas enkursigata aliloken survoje elen. Sekvu la respondon per fontspezifa serĉo, kaj la ĉirkaŭvojo fariĝos videbla.

Kion la kerno efektive enkursigas: la fonta adreso

La tenilo, kiun vi bezonas, estas la loka adreso, kiun la servo uzas por respondoj. Sur gastiganto kun la ilustra eth0-adreso 192.0.2.10/24 kaj pordego 192.0.2.1, tiu adreso ĉeestas sur la interfaco. Sur nuba VM, la publika adreso povas esti tradukata supre kaj foresti el la gasto, do uzu la adreson, kiun la gastiganto efektive tenas.

Inspektu la nunan staton antaŭ ol rezervi tabelan numeron aŭ regulan prioritaton. Ekzistantaj politikaj reguloj povas ombrigi novan, kaj malnova tabelo kun la sama numero eble jam portas nerilatajn vojojn:

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

Poste elektu tabelon laŭ fonto. La regulo kongruas kun respondoj, kiuj jam portas 192.0.2.10, ĝuste la loke finita trafiko, kiun vi volas escepti. Plusendita trafiko kaj paketoj de aliaj lokaj adresoj ne kongruas.

Konstruu kompletan revenan tabelon, ne duonan defaŭlton

Tabelo kun nur defaŭlta vojo ne sufiĉas. La kerno ankoraŭ devas solvi la pordegon, kaj tiu solvo bezonas la konektitan prefikson en la sama tabelo. Tabelo, al kiu mankas tiu prefikso, malsukcesas ĉe pordega solvo eĉ kiam ĝia defaŭlta vojo aspektas ĝusta. Aldonu ambaŭ, poste direktu la fontan regulon al la tabelo:

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

Uzu la realan prefikson kaj pordegon anstataŭ kopii la ekzemplon. Nuba interfaco agordita kiel /32 kun surliga pordego bezonas alian konektitan vojon, kaj tabelo konstruita el la malĝusta prefikso malsukcesas ĉe la unua salteto. La atributo src indikas la preferatan fonton por tiu vojo; ĝi ne anstataŭas la fontan regulon.

Ankaŭ la ordo gravas. Larĝa regulo kun pli malalta prioritata numero estas taksata unue, do la fonta regulo devas esti atingita antaŭ iu ajn regulo, kiu resendus tiun trafikon al la ĉefa tabelo. Kontrolu la prioritatojn per ip rule show post aldonado, ne nur ĉe ekŝargo.

Kontrolu per fontspezifa serĉo

Petu la kernon enkursigi testan celon el la serva adreso. La respondo devus nomi eth0 kaj la WAN-pordegon, ne la tunelon:

ip -4 route get 198.51.100.25 from 192.0.2.10

Poste faru novan rajtigitan konekton kaj observu ambaŭ direktojn. Serĉo, kiu elektas la ĝustan tabelon dum la viva konekto ankoraŭ malsukcesas, indikas inversvojan filtradon aŭ fajroŝirman regulon, ne la tabelon. Kontrolu tiujn regilojn antaŭ ol malŝalti ion ajn tutmonde.

Metu la finajn vojojn kaj la regulon sub la retadministrilon, kiu posedas la interfacon. Adresŝanĝoj, DHCP-renovigo kaj VPN-rekonektoj ĉiuj reskribas la kernan staton, kaj permane aldonita regulo malaperas aŭ montras al kaduka pordego post la sekva evento.

Kie ĉi tiu escepto haltas

La regulo esceptas loke finitan trafikon de unu fonta adreso. Ĝi ne kovras pordojn publikigitajn de Docker, DNAT aŭ servojn plusenditajn tra la gastiganto, ĉar tiuj paketoj estas enkursigataj kiel plusendita trafiko kaj neniam portas la lokan fonton de la gastiganto same. Tiaj dezajnoj kutime bezonas markon metitan ĉe la enirejo kaj regulon, kiu kongruas kun la marko.

Ĝi ankaŭ ne igas la publikan adreson de la gastiganto aperi sur la interfaco. Kiam supra NAT posedas tiun adreson, la respondo ankoraŭ devas eliri laŭ la vojo, kiun tiu NAT atendas, kaj tial la WAN-tabelo devas speguli la originan pordegon kaj prefikson anstataŭ divenitan publikan gamon.

Tenu la escepton dokumentita kun ĝia tabela numero, regula prioritato kaj la preciza fonta adreso. La sekva ŝanĝo al la VPN aŭ la interfaco povas silente rompi ĝin, kaj noto, kiu nomas la tri valorojn, estas pli rapida kontroli ol retrovado de la simptomo el klienta raporto.

Se la servo ankoraŭ respondas laŭ la malĝusta vojo post kiam la fontspezifa serĉo sukcesas, komparu la fontan adreson de la viva ingo kun tiu en la regulo. Servo ligita al ĵokera adreso povas elekti alian fonton ol la adreso, kiun vi testis, kaj tiu malkongruo estas la restanta breĉo.