Adresă peer PPP sau endpoint VPN: care intră în via

O singură linie pe o interfață PPP lămurește cea mai mare parte a dezbaterii de rutare de pe o cutie VPN: adresa interioară și peer-ul tipărit lângă ea. Citiți acea pereche ca pe o subrețea minusculă și veți căuta o poartă care nu există. Citiți-o ca pe cele două capete ale unei singure legături și următorul salt devine evident. Comparația de aici este între aceste două lecturi, pentru că fiecare tabel construit după aceea moștenește lectura pe care ați ales-o. Nimic despre endpoint-ul VPN exterior nu este decis de niciuna dintre ele.

Două lecturi ale aceleiași linii de interfață

Luați o sesiune în care interfața raportează inet 10.64.3.9 peer 10.64.3.1/32. Lectura ca subrețea tratează 10.64.3.9 ca un host singur pe o insulă /32 și apoi caută un router pentru a ajunge dincolo de ea. Deoarece singura altă adresă de pe legătură este peer-ul, această lectură ajunge să propună 10.64.3.9 însuși ca poartă, ceea ce este circular.

Lectura ca endpoint este cea documentată. Pe o interfață punct-la-punct, peer numește capătul îndepărtat al acelei singure legături, deci 10.64.3.1 este următorul salt utilizabil, iar 10.64.3.9 este mereu doar o adresă sursă.

Această diferență guvernează ce poate apărea în via. Scrierea adresei locale acolo produce o rută pe care kernelul nu o poate rezolva către un vecin, așa că intrarea fie eșuează validarea, fie înghite traficul în timp ce arată perfect sănătoasă într-o listare. Peer-ul funcționează pentru că este o destinație reală pe legătură. Ambele lecturi sunt de acord asupra endpoint-ului VPN exterior, care este o identitate complet separată: se ajunge la el prin underlay, nu prin tunelul pe care îl termină.

Ce a instalat deja sesiunea

Înainte de a scrie vreun tabel propriu, tipăriți ce a venit cu legătura. O integrare PPP acceptată instalează de obicei o rută de dispozitiv și o rută de peer la configurarea sesiunii, iar cele două intrări codifică deja lectura corectă.

ip -4 addr show dev ppp0
ip route show dev ppp0
ip route show table main | head -n 5

O rută de dispozitiv precum 10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 nu poartă nici o poartă pentru că interfața însăși este calea. O rută care numește peer-ul cu via este un alt obiect, cu altă durată de viață, și dispare când cade sesiunea. Copierea oricăreia dintre cele două forme într-un tabel persistent fără a verifica modul în care este reinstalată este motivul obișnuit pentru care un tunel care funcționa își pierde ruta după o reconectare.

Comparați cele două listări în loc să vă bazați pe memorie. Dacă ruta peer-ului există în main dar tabelul suplimentar este gol, ați învățat ceva ce linia de adrese nu v-a spus niciodată.

O regulă și un tabel sunt decizii separate

Selectarea unui tabel și umplerea lui sunt pași independenți, iar comparația contează aici pentru că cele două sunt adesea confundate la depanare. O regulă care trimite trafic marcat către tabelul 100 nu face nimic dacă tabelul 100 nu are o rută potrivită, iar un tabel bine populat este inaccesibil dacă nicio regulă nu indică spre el.

Jumătate de rută implicită nu este o rută implicită. Un singur 0.0.0.0/1 acoperă jumătatea inferioară a spațiului IPv4, deci o politică ce intenționează să prindă tot are nevoie și de 128.0.0.0/1 corespunzător, sau de un default autentic. Citirea unei configurații funcționale și copierea uneia dintre cele două jumătăți este modul în care oamenii ajung cu o buclă de rutare care se rupe doar la anumite destinații.

Lăsați excepții deliberate pentru adresele care trebuie să rămână în LAN, și decideți ce se întâmplă când căutarea nu găsește nimic în tabelul selectat. O rută de rezervă explicită este mai ușor de raționat decât un tabel gol, care returnează un rezultat inaccesibil și face aplicația să pară stricată în loc de rutată greșit.

Puneți căutării întrebarea pe care o pune aplicația voastră

ip route get rezolvă o cale, ip route show listează intrările stocate, iar cele două pot fi în dezacord fără ca vreuna să fie greșită. Includeți contextul sursă, pentru că regulile bazate pe sursă se potrivesc doar când căutarea transportă o sursă.

ip route get 198.51.100.23 from 10.64.3.9
ip route get 198.51.100.23 from 10.64.3.9 iif ppp0
ip -4 rule show

Prima comandă pune întrebarea din partea hostului. A doua adaugă o interfață de intrare, care este mai aproape de ceea ce experimentează traficul redirecționat, iar răspunsul indică adesea un alt tabel. Niciuna dintre destinații nu este un serviciu de test live, 198.51.100.23 este o adresă de documentație, așa că înlocuiți-o cu un host pe care aveți voie să îl sondați.

Chiar și o căutare corectă dovedește doar că a fost aleasă o cale. Nu spune nimic despre dacă partea cealaltă acceptă traficul sau dacă răspunsul poate reveni prin același raționament.

Unde se răstoarnă comparația

Traficul hostului și traficul redirecționat nu iau doar căutări diferite, întâlnesc filtre diferite la întoarcere. Linux aplică validarea căii inverse folosind cea mai strictă dintre setările pentru toate interfețele și pentru interfața receptoare, așa că schimbarea valorii unei interfețe poate să nu aibă niciun efect vizibil. Rutarea bazată pe marcă adaugă relația src_valid_mark, în care marca trebuie să corespundă pentru ca o sursă să fie considerată validă.

Dacă răspunsurile dispar în timp ce rutarea de ieșire pare corectă, citiți valorile efective înainte de a le atinge, și schimbați-le doar cu un motiv de politică declarat.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.ppp0.rp_filter
sysctl net.ipv4.conf.all.src_valid_mark

Alegeți între cele două proiecte pe baza dovezilor: dacă aplicația se leagă de adresa PPP, o regulă sursă plus un tabel care conține ruta peer-ului sunt suficiente. Dacă cutia redirecționează pentru un LAN din spate, aveți nevoie și ca contextul de intrare și calea de întoarcere să fie de acord. Când nu sunt de acord, corectați proprietatea rutei în loc să relaxați validarea pentru toată mașina.