Un peer VPN face ping către alte interfețe pentru că sunt locale
Tabelul de rutare local trimite pachetele către orice adresă pe care o deține gazda, indiferent pe ce interfață se află. Setările de redirecționare nu intră niciodată pe acea cale.
Un client WireGuard se conectează și face ping către o adresă de pe o interfață complet diferită, iar răspunsul sosește. Capturile arată cererea doar pe tunel. Nimic nu este stricat, iar setarea de redirecționare dezactivată cu grijă nu are nicio legătură. Aceasta este o comparație între două căi care arată la fel pe o diagramă și sunt complet diferite în kernel.
Una dintre căi redirecționează pachete pentru altcineva; cealaltă le livrează gazdei înseși.
Un pachet adresat gazdei rămâne în gazdă
Clientul îndepărtat trimite un pachet IP către o adresă pe care o deține gazda. Rutarea pune o singură întrebare despre acel pachet: este această destinație locală? Fiecare adresă pe care o are gazda apare în tabelul de rutare local, și acel tabel este consultat înaintea celui principal, așa că pachetul merge în stiva proprie a gazdei în loc să iasă prin altă interfață. Răspunsul este generat local, și se întoarce prin tunel pentru că de acolo a venit interogarea.
Acesta este întregul mecanism. Nu are loc nicio redirecționare, nu este implicată nicio schimbare a stării interfeței, iar adresa în cauză nu trebuie să fie accesibilă din orice alt loc.
De ce ip_forward nu se aplică
Redirecționarea guvernează pachetele care trebuie să plece printr-o altă interfață decât cea pe care au sosit. Un ping către gazda însăși nu ia niciodată acea cale: pachetul este consumat local, iar răspunsul este generat local. De aceea, setarea net.ipv4.ip_forward=0 nu schimbă nimic aici, iar o regulă din lanțul de redirecționare nu vede niciodată acel trafic. Controlul corect se află pe calea de intrare, limitat de interfața de intrare sau de sursă.
De aceea, dezactivarea redirecționării și presupunerea că gazda este izolată produc o falsă senzație de siguranță.
Citiți tabelul local care a decis
ip rule show raportează de obicei o regulă cu prioritate zero care trimite toate căutările mai întâi către tabelul local, iar ip route show table local listează adresele proprii ale gazdei cu domeniu local. Acel tabel include adrese de pe interfețe oprite administrativ dar încă configurate. Adresele IPv4 atribuite static supraviețuiesc de obicei unei căderi a legăturii, și de aceea un ping către un bridge oprit poate reuși încă și poate surprinde operatorul.
IPv6 nu este de acord exact în acest punct. Adresele sale sunt de obicei retrase când cade legătura, dacă keep_addr_on_down nu este setat. Comparați familiile în loc să presupuneți că o regulă le acoperă pe amândouă.
La ce ajunge de fapt un peer
Un răspuns de la adresa proprie a routerului pe un segment nu spune nimic despre mașinile din spatele acelui segment. Peerul nu poate ajunge la o gazdă din spatele celeilalte interfețe pe această cale; ajunge doar la adresele pe care le deține routerul însuși. Testarea unui serviciu pe o gazdă LAN separată, în loc de ping către adresa routerului, este ceea ce stabilește dacă redirecționarea este permisă deloc.
Restrângerea unui peer la serviciile legate de adresa tunelului este o chestiune de politică de intrare. Permiteți serviciul dorit pe interfața tunelului și restricționați sursele care îl pot folosi, pentru că pachetul chiar ajunge acolo.
Verificați și adresele pe care intenționați să le retrageți. Eliminarea unei adrese de pe o interfață este mai fiabilă decât stivuirea regulilor de firewall peste o adresă învechită.