De ce un client VPN din rețeaua locală a biroului pierde fiecare răspuns

Un laptop stă în /24 al biroului prin Ethernet și se alătură totodată unui server OpenVPN care trăiește în același /24. Un coleg face ping la adresa tunelului; cererea ajunge clar, și nimic nu se întoarce. Jurnalul tunelului este curat și navigarea încă funcționează, deci tunelul este suspectul greșit. Validarea sursei IPv4 pe mașina care primește aruncă pachetul înainte ca ceva să-l citească.

Aruncarea are loc înainte ca ceva să citească pachetul

Validarea sursei pune o singură întrebare despre fiecare pachet care sosește: dacă această gazdă ar răspunde acelei surse, ar ieși răspunsul pe interfața pe care pachetul tocmai a sosit? Când răspunsul este nu, nucleul aruncă pachetul la sosire. Nici un socket și nici o cale de redirecționare nu îl văd vreodată, de aceea o captură pe tunel înregistrează în continuare o cerere pe care aplicația nu o primește niciodată.

Clientul de aici ține 10.66.0.9 pe tunelul său, iar serverul OpenVPN răspunde la 192.168.80.10 în interiorul prefixului biroului. Un coleg la 192.168.80.25 face ping la adresa tunelului, așa că cererea traversează rețeaua locală, serverul o direcționează în tunel, și ea sosește pe interfața de tunel a clientului purtând o adresă de sursă a biroului. În tabela de rutare a acelei mașini prefixul biroului aparține dispozitivului Ethernet, nu tunelului. Validarea compară interfața de sosire cu ruta, găsește o nepotrivire și aruncă pachetul, așa că colegul vede o pierdere totală în timp ce ambele capete raportează un tunel sănătos.

Direcția oglindă are aceeași formă: când clientul pornește spre birou, răspunsurile pot fi aruncate pe partea biroului din exact același motiv. O corecție verificată într-o singură direcție tinde să revină ca un al doilea tichet.

Dovediți modul în vigoare înainte de a atinge vreun sysctl

Citiți valorile efective în loc să aveți încredere într-un implicit al distribuției, pentru că setarea pe interfață este doar jumătate din decizie. Modul în vigoare este cel mai mare dintre valoarea interfeței și valoarea all, așa că un zero pe interfața tunelului nu înseamnă nimic cât timp all este unu. Decizia modului strict este o decizie de rutare, așa că rulați căutarea pe care o rulează nucleul și comparați răspunsul cu interfața pe care pachetul a sosit de fapt.

tcpdump -ni tun0 icmp and host 192.168.80.25
ip route get 192.168.80.25
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.tun0.rp_filter

Apoi repetați pingul urmărind contorul de erori. Un contor care crește lângă o cerere pe care captura o arată deja este semnătura acestei aruncări, nu a unei rute lipsă. Activați jurnalizarea pachetelor marțiene cât sunteți acolo, ca nucleul să numească sursa și interfața pe care le-a respins. Împreună exclud cifrul, paravanul și un iroute lipsă ca explicații.

Notați linia de bază înainte de a schimba ceva: ambele valori, dispozitivul ales de căutare și contorul pe care l-ați urmărit. Acea înregistrare este ce vă spune mai târziu dacă schimbarea a făcut ce credeți.

Ce acceptă de fapt fiecare mod rp_filter

Nucleul expune trei valori pe interfață, și nu sunt trei nuanțe ale unei singure reguli. Zero dezactivează verificarea. Unu este strict și cere ca sursa să fie rutată înapoi prin interfața de sosire. Doi este lax și cere doar să existe vreo rută către sursă în tabel, oriunde ar indica.

Rândul care contează aici este cel lax, și ceea ce continuă să respingă. O sursă falsificată care este rutabilă oriunde în tabelul dumneavoastră trece, în timp ce o sursă fără nicio rută este încă refuzată. Pe un laptop este o concesie îngustă; pe un router care redirecționează traficul altor persoane este largă. Modul aparține gazdei, așa că același număr poartă o greutate diferită în cele două locuri.

Care rând este necesar acestei topologii reiese din tabel și nu din obișnuință. Pachetul este legitim și sursa lui este rutabilă, așa că cel lax îl acceptă și cel strict nu. Nimic din caz nu cere zero, iar alegerea lui zero ar elimina o verificare care aici nu costă nimic.

Alegeți cea mai mică schimbare care elimină ambiguitatea

Modul lax este cea mai mică schimbare potrivită, și este o reducere reală a rigorii, nu un comutator inofensiv. O opțiune mai bună există oricând topologia o permite: eliminați suprapunerea, și ambiguitatea dispare.

Unde prefixul biroului este necesar doar prin Ethernet, scoateți-l din rutele pe care le trage profilul și adresa devine accesibilă printr-o singură cale. Când cele două căi trebuie într-adevăr să coexiste, fixați sursa și dispozitivul cu o regulă de politică în loc să slăbiți validarea pe fiecare interfață. Asta păstrează filtrarea strictă pentru tot restul de pe mașină și documentează excepția acolo unde următorul inginer o va căuta.

Orice cale ați alege, înregistrați-o într-un drop-in sysctl și nu într-o comandă vie. Setați cheile all și default împreună, ca o reconectare să nu poată restabili în tăcere modul strict.

# /etc/sysctl.d/99-rp-filter.conf
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2
sysctl --system

La ce renunță modul lax, și unde

Modul lax respinge în continuare o sursă pe care nicio rută nu ar putea-o atinge, și încetează să mai respingă o sursă falsificată care se întâmplă să fie rutabilă. Pe un laptop este o concesie îngustă. Pe un dispozitiv care redirecționează trafic ce nu îi aparține, aceeași alegere este mult mai largă. Prin urmare aceeași setare poartă două semnificații foarte diferite în funcție de locul unde rulează.

Oprirea completă a verificării pe o gazdă care redirecționează trafic pentru alți oameni este singura reparație de evitat. Zero aruncă validarea pe care modul lax o păstrează cu grijă. Dacă gazda redirecționează pentru alții, argumentați în schimb pentru opțiunea regulii de politică din secțiunea anterioară.

Lăsați o notă care numește cele două interfețe, prefixul suprapus și testul exact care reușește acum. Aceasta este mai utilă următorului inginer decât o linie care spune că filtrarea a fost ajustată.