Kāpēc jūsu publiskais Linux pakalpojums atbild caur VPN

Nekas ligzdā neatceras, kura saskarne pārvadāja pieprasījumu, tāpēc pilna tuneļa VPN noklusējuma maršruts var pārtvert atbildi, kas pieder WAN. Pakalpojums neignorē ienākošo saskarni; Linux maršrutē lokāli ģenerētu atbildi pēc galamērķa un avota politikas. Uz avotu balstīts noteikums var nosūtīt tikai pakalpojuma atbildes pa pilnu WAN tabulu, atstājot parasto izeju tunelī. Ports paliek atvērts, kamēr atbilde iziet pa nepareizo ceļu, tāpēc simptoms šķiet vienpusējs.

Nepareizais priekšstats: atbildes seko saskarnei, pa kuru tās ienāca

Šķiet loģiski, ka paketei, kas ienāk pa eth0, jāiziet pa eth0. Bezstāvokļa pakešu filtri ir jāraksta tā, un tcpdump ienākošajā pusē rāda pieprasījumu tieši tur, kur to gaida. Maršrutēšana tā nedarbojas trafikam, ko ģenerē pats resursdators.

Tiklīdz pakalpojums pieņem savienojumu, tā atbilde ir jauna, lokāli ģenerēta pakete. Kodols pārbauda maršrutēšanas noteikumus atbildes galamērķim un avotam, un VPN noklusējuma maršruts ir pilnīgi derīga atbilde. Nekas ligzdā neatceras, kura saskarne pārvadāja pieprasījumu.

Tāpēc simptoms šķiet vienpusējs: pieprasījumi ienāk, atbildes pazūd. Tāpēc arī ugunsmūra noteikuma pievienošana ienākošajam portam neko nemaina. Pakete netiek bloķēta ceļā uz iekšu; tā tiek maršrutēta citur ceļā uz āru. Izsekojiet atbildei ar avotu kvalificētu meklēšanu, un apvedceļš kļūs redzams.

Ko kodols patiešām maršrutē: avota adresi

Nepieciešamais rokturis ir lokālā adrese, ko pakalpojums izmanto atbildēm. Resursdatorā ar ilustratīvo eth0 adresi 192.0.2.10/24 un vārteju 192.0.2.1 šī adrese ir saskarnē. Mākoņa VM publiskā adrese var būt pārveidota augstāk un viesī nebūt, tāpēc izmantojiet adresi, kas resursdatoram patiešām ir.

Pārbaudiet pašreizējo stāvokli, pirms rezervējat tabulas numuru vai noteikuma prioritāti. Esošie politikas noteikumi var aizēnot jauno, un veca tabula ar to pašu numuru jau var saturēt nesaistītus maršrutus:

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

Pēc tam izvēlieties tabulu pēc avota. Noteikums atbilst atbildēm, kas jau satur 192.0.2.10, tieši lokāli pabeigtajam trafikam, ko vēlaties atbrīvot. Pārsūtītais trafiks un paketes no citām lokālajām adresēm neatbilst.

Veidojiet pilnu atgriešanās tabulu, nevis pusi no noklusējuma

Ar tabulu, kurā ir tikai noklusējuma maršruts, nepietiek. Kodolam joprojām jāatrisina vārteja, un šim risinājumam vajadzīgs savienotais prefikss tajā pašā tabulā. Tabula, kurai trūkst šī prefiksa, neizdodas vārtejas atrisināšanā pat tad, ja tās noklusējuma maršruts izskatās pareizs. Pievienojiet abus, pēc tam novirziet avota noteikumu uz tabulu:

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

Izmantojiet īsto prefiksu un vārteju, nevis kopējiet piemēru. Mākoņa saskarnei, kas konfigurēta kā /32 ar on-link vārteju, vajadzīgs cits savienotais maršruts, un tabula, kas veidota no nepareiza prefiksa, neizdodas pirmajā lēcienā. Atribūts src norāda vēlamo avotu šim maršrutam; tas neaizstāj avota noteikumu.

Svarīga ir arī secība. Plašs noteikums ar zemāku prioritātes numuru tiek izvērtēts pirmais, tāpēc avota noteikums jāsasniedz pirms jebkura noteikuma, kas šo trafiku sūtītu atpakaļ uz galveno tabulu. Pārbaudiet prioritātes ar ip rule show pēc pievienošanas, ne tikai startēšanas laikā.

Pārbaudiet ar avotu kvalificētu meklēšanu

Palūdziet kodolam maršrutēt testa galamērķi no pakalpojuma adreses. Atbildei jānosauc eth0 un WAN vārteja, nevis tunelis:

ip -4 route get 198.51.100.25 from 192.0.2.10

Pēc tam izveidojiet jaunu autorizētu savienojumu un vērojiet abus virzienus. Meklēšana, kas izvēlas pareizo tabulu, kamēr dzīvais savienojums joprojām neizdodas, norāda uz reversā ceļa filtrēšanu vai ugunsmūra noteikumu, nevis uz tabulu. Pārbaudiet šīs vadības pirms kaut kā globālas atslēgšanas.

Novietojiet galīgos maršrutus un noteikumu zem tīkla pārvaldnieka, kuram pieder saskarne. Adreses izmaiņas, DHCP atjaunošana un VPN atkārtota savienošana pārraksta kodola stāvokli, un ar roku pievienots noteikums pazūd vai norāda uz novecojušu vārteju pēc nākamā notikuma.

Kur šis izņēmums beidzas

Noteikums atbrīvo lokāli pabeigtu trafiku no vienas avota adreses. Tas neaptver Docker publicētos portus, DNAT vai pakalpojumus, kas pārsūtīti caur resursdatoru, jo šīs paketes tiek maršrutētas kā pārsūtīts trafiks un nekad nenes resursdatora lokālo avotu tādā pašā veidā. Šādiem risinājumiem parasti vajadzīga atzīme, kas uzstādīta ieejā, un noteikums, kas atbilst atzīmei.

Tas arī nepanāk, ka resursdatora publiskā adrese parādās saskarnē. Kad augšposma NAT pārvalda šo adresi, atbildei joprojām jāiziet pa ceļu, kuru šis NAT gaida, tāpēc WAN tabulai jāatspoguļo sākotnējā vārteja un prefikss, nevis minēts publiskais diapazons.

Turiet izņēmumu dokumentētu ar tā tabulas numuru, noteikuma prioritāti un precīzu avota adresi. Nākamās izmaiņas VPN vai saskarnē var to klusi salauzt, un piezīme, kas nosauc trīs vērtības, ir ātrāk pārbaudāma nekā simptoma atklāšana no jauna klienta ziņojumā.

Ja pakalpojums joprojām atbild pa nepareizo ceļu pēc tam, kad avotu kvalificētā meklēšana ir izdevusies, salīdziniet dzīvās ligzdas avota adresi ar to, kas norādīta noteikumā. Pakalpojums, kas piesaistīts aizstājējadresei, var izvēlēties citu avotu nekā pārbaudītā adrese, un šī neatbilstība ir atlikušā plaisa.