De ce serviciul dvs. Linux public răspunde prin VPN

Nimic din socket nu își amintește ce interfață a transportat cererea, așa că o rută implicită de VPN cu tunel complet poate captura un răspuns care aparține WAN-ului. Serviciul nu ignoră interfața de intrare; Linux rutează un răspuns generat local după destinație și politica de sursă. O regulă bazată pe sursă poate trimite în schimb doar răspunsurile serviciului printr-un tabel WAN complet, lăsând ieșirea obișnuită pe tunel. Portul rămâne deschis în timp ce răspunsul iese pe calea greșită, motiv pentru care simptomul pare unilateral.

Ideea greșită: răspunsurile urmează interfața pe care au sosit

Pare logic ca un pachet care sosește pe eth0 să iasă pe eth0. Filtrele de pachete fără stare pot fi scrise astfel, iar tcpdump pe partea de intrare arată cererea exact acolo unde este așteptată. Rutarea nu funcționează așa pentru traficul pe care gazda îl generează ea însăși.

După ce serviciul acceptă conexiunea, răspunsul său este un pachet nou generat local. Nucleul consultă regulile de rutare pentru destinația și sursa răspunsului, iar ruta implicită a VPN-ului este un răspuns perfect valid. Nimic din socket nu își amintește ce interfață a transportat cererea.

De aceea simptomul pare unilateral: cererile sosesc, răspunsurile dispar. De aceea nici adăugarea unei reguli de firewall pentru portul de intrare nu schimbă nimic. Pachetul nu este blocat pe drumul spre interior; este rutat în altă parte pe drumul spre exterior. Urmăriți răspunsul cu o căutare calificată pe sursă și ocolul devine vizibil.

Ce rutează de fapt nucleul: adresa de sursă

Mânerul de care aveți nevoie este adresa locală pe care serviciul o folosește pentru răspunsuri. Pe o gazdă cu adresa eth0 ilustrativă 192.0.2.10/24 și poarta 192.0.2.1, acea adresă este prezentă pe interfață. Pe un VM în cloud, adresa publică poate fi tradusă mai sus și absentă din oaspete, așa că folosiți adresa pe care gazda o are cu adevărat.

Inspectați starea curentă înainte de a rezerva un număr de tabel sau o prioritate de regulă. Regulile de politică existente pot umbri una nouă, iar un tabel vechi cu același număr poate deja transporta rute nelegate:

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

Apoi selectați un tabel după sursă. Regula se potrivește cu răspunsurile care transportă deja 192.0.2.10, exact traficul terminat local pe care doriți să-l scutiți. Traficul redirecționat și pachetele din alte adrese locale nu se potrivesc.

Construiți un tabel de retur complet, nu jumătate de rută implicită

Un tabel cu doar o rută implicită nu este suficient. Nucleul trebuie să rezolve în continuare poarta, iar acea rezolvare are nevoie de prefixul conectat în același tabel. Un tabel căruia îi lipsește acel prefix eșuează la rezolvarea porții chiar și când ruta sa implicită pare corectă. Adăugați ambele, apoi îndreptați regula de sursă spre 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

Folosiți prefixul și poarta reale în loc să copiați exemplul. O interfață din cloud configurată ca /32 cu o poartă on-link are nevoie de o altă rută conectată, iar un tabel construit din prefixul greșit eșuează la primul salt. Atributul src indică sursa preferată pentru acea rută; nu înlocuiește regula de sursă.

Și ordinea contează. O regulă largă cu un număr de prioritate mai mic este evaluată prima, așa că regula de sursă trebuie atinsă înaintea oricărei reguli care ar trimite acest trafic înapoi în tabelul principal. Verificați prioritățile cu ip rule show după ce o adăugați, nu doar la pornire.

Verificați cu o căutare calificată pe sursă

Rugați nucleul să ruteze o destinație de test din adresa serviciului. Răspunsul ar trebui să numească eth0 și poarta WAN, nu tunelul:

ip -4 route get 198.51.100.25 from 192.0.2.10

Apoi stabiliți o conexiune autorizată nouă și observați ambele direcții. O căutare care selectează tabelul corect în timp ce conexiunea reală încă eșuează indică filtrarea pe calea inversă sau o regulă de firewall, nu tabelul. Verificați acele controale înainte de a dezactiva ceva global.

Puneți rutele finale și regula sub managerul de rețea care deține interfața. Modificările de adresă, reînnoirea DHCP și reconectările VPN rescriu tot starea nucleului, iar o regulă adăugată manual dispare sau indică o poartă învechită după următorul eveniment.

Unde se oprește această excepție

Regula scutește traficul terminat local dintr-o singură adresă de sursă. Nu acoperă porturile publicate de Docker, DNAT sau serviciile redirecționate prin gazdă, deoarece acele pachete sunt rutate ca trafic redirecționat și nu poartă niciodată sursa locală a gazdei în același mod. Astfel de proiectări au nevoie de obicei de un marcaj setat la intrare și de o regulă care se potrivește cu marcajul.

De asemenea, nu face adresa publică a gazdei să apară pe interfață. Când un NAT din amonte deține acea adresă, răspunsul trebuie totuși să iasă pe calea pe care acel NAT o așteaptă, motiv pentru care tabelul WAN trebuie să reflecte poarta și prefixul originale, nu un interval public ghicit.

Țineți excepția documentată cu numărul tabelului, prioritatea regulii și adresa de sursă exactă. Următoarea modificare a VPN-ului sau a interfeței o poate rupe în tăcere, iar o notă care numește cele trei valori se verifică mai repede decât redescoperirea simptomului dintr-un raport de client.

Dacă serviciul încă răspunde pe calea greșită după ce căutarea calificată pe sursă reușește, comparați adresa de sursă a socketului activ cu cea din regulă. Un serviciu legat de o adresă wildcard poate alege o sursă diferită de adresa pe care ați testat-o, iar această nepotrivire este golul rămas.