Waarom jou publieke Linux-diens eerder deur die VPN antwoord

Niks in die socket onthou watter koppelvlak die versoek gedra het nie, so ’n voltonnel-VPN-standaardroete kan ’n antwoord vasvang wat op die WAN hoort. Die diens ignoreer nie die inkomende koppelvlak nie; Linux stuur ’n plaaslik gegenereerde antwoord volgens bestemming en bronbeleid. ’n Brongebaseerde reël kan eerder net die diens se antwoorde deur ’n volledige WAN-tabel stuur en gewone uitgang op die tonnel laat. Die poort bly oop terwyl die antwoord deur die verkeerde pad vertrek, en daarom lyk die simptoom eensydig.

Die wanopvatting: antwoorde volg die koppelvlak waarop hulle aangekom het

Dit voel logies dat ’n pakket wat op eth0 aankom, op eth0 moet vertrek. Toestandlose pakkettfilters kan so geskryf word, en tcpdump aan die inkomende kant wys die versoek presies waar jy dit verwag. Roetering werk nie so vir verkeer wat die gasheer self skep nie.

Sodra die diens die verbinding aanvaar, is sy antwoord ’n nuwe plaaslik gegenereerde pakket. Die kernel raadpleeg die roeteringsreëls vir die antwoord se bestemming en bron, en die VPN se standaardroete is ’n heeltemal geldige antwoord. Niks in die socket onthou watter koppelvlak die versoek gedra het nie.

Daarom lyk die simptoom eensydig: versoeke kom in, antwoorde verdwyn. Daarom verander ’n vuurmuurreël vir die inkomende poort ook niks nie. Die pakket word nie op pad in geblokkeer nie; dit word op pad uit elders heen gestuur. Volg die antwoord met ’n brongeoormerkte soektog, en die ompad word sigbaar.

Wat die kernel werklik roeteer: die bronadres

Die handvatsel wat jy nodig het, is die plaaslike adres wat die diens vir antwoorde gebruik. Op ’n gasheer met die illustratiewe eth0-adres 192.0.2.10/24 en poortwag 192.0.2.1 is daardie adres op die koppelvlak teenwoordig. Op ’n wolkskikking kan die publieke adres stroomop vertaal en in die gas afwesig wees, so gebruik die adres wat die gasheer werklik hou.

Ondersoek die huidige toestand voordat jy ’n tabelnommer of reëlprioriteit reserveer. Bestaande beleidsreëls kan ’n nuwe een oorskadu, en ’n ou tabel met dieselfde nommer kan reeds onverwante roetes dra:

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

Kies dan ’n tabel op grond van die bron. Die reël pas by antwoorde wat reeds 192.0.2.10 dra, presies die plaaslik beëindigde verkeer wat jy wil vrystel. Deurgevoerde verkeer en pakkette van ander plaaslike adresse pas nie.

Bou ’n volledige terugtabel, nie ’n halwe standaard nie

’n Tabel met net ’n standaardroete is nie genoeg nie. Die kernel moet nog die poortwag oplos, en daardie oplossing het die gekoppelde voorvoegsel in dieselfde tabel nodig. ’n Tabel wat daardie voorvoegsel mis, faal by poortwagoplossing selfs wanneer sy standaardroete korrek lyk. Voeg albei by en wys die bronreël dan na die tabel:

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

Gebruik die werklike voorvoegsel en poortwag eerder as om die voorbeeld te kopieer. ’n Wolkkoppelvlak wat as ’n /32 met ’n on-link-poortwag opgestel is, het ’n ander gekoppelde roete nodig, en ’n tabel wat uit die verkeerde voorvoegsel gebou is, faal by die eerste sprong. Die src-kenmerk noem die voorkeurbron vir daardie roete; dit vervang nie die bronreël nie.

Orde maak ook saak. ’n Breë reël met ’n laer prioriteitsnommer word eerste geëvalueer, so die bronreël moet bereik word voordat enige reël wat hierdie verkeer na die hooftabel sou stuur. Kontroleer die prioriteite met ip rule show nadat jy dit bygevoeg het, nie net by selflaai nie.

Verifieer met ’n brongeoormerkte soektog

Vra die kernel om ’n toetsbestemming vanaf die diensadres te roeteer. Die antwoord behoort eth0 en die WAN-poortwag te noem, nie die tonnel nie:

ip -4 route get 198.51.100.25 from 192.0.2.10

Maak dan ’n nuwe gemagtigde verbinding en kyk na albei rigtings. ’n Soektog wat die regte tabel kies terwyl die lewendige verbinding steeds faal, wys na tru-pad-filtering of ’n vuurmuurreël, nie na die tabel nie. Kontroleer daardie beheermaatreëls voordat jy enigiets globaal afskakel.

Plaas die finale roetes en reël onder die netwerkbestuurder wat die koppelvlak besit. Adresveranderings, DHCP-hernuwing en VPN-herverbindings herskryf almal kerneltoestand, en ’n reël wat met die hand bygevoeg is, verdwyn of wys na ’n verouderde poortwag ná die volgende gebeurtenis.

Waar hierdie uitsondering stop

Die reël stel plaaslik beëindigde verkeer van een bronadres vry. Dit dek nie Docker-gepubliseerde poorte, DNAT of dienste wat deur die gasheer deurgestuur word nie, want daardie pakkette word as deurvoerverkeer gerouteer en dra nooit dieselfde manier die gasheer se plaaslike bron nie. Sulke ontwerpe het gewoonlik ’n merk nodig wat by inkom gestel word en ’n reël wat by die merk pas.

Dit laat ook nie die gasheer se publieke adres op die koppelvlak verskyn nie. Wanneer ’n stroomop-NAT daardie adres besit, moet die antwoord steeds deur die pad vertrek wat daardie NAT verwag, en daarom moet die WAN-tabel die oorspronklike poortwag en voorvoegsel weerspieël eerder as ’n gerate publieke reeks.

Hou die uitsondering gedokumenteer met sy tabelnommer, reëlprioriteit en die presiese bronadres. Die volgende verandering aan die VPN of die koppelvlak kan dit stilweg breek, en ’n nota wat die drie waardes noem, is vinniger om te kontroleer as om die simptoom uit ’n klantverslag te herontdek.

As die diens steeds op die verkeerde pad antwoord nadat die brongeoormerkte soektog slaag, vergelyk die lewendige socket se bronadres met dié in die reël. ’n Diens wat aan ’n wildcard-adres gebind is, kan ’n ander bron kies as die adres wat jy getoets het, en daardie wanverhouding is die oorblywende gaping.