Tabelele de rutare sunt citite ca stricate de fiecare dată când coloana porții rămâne goală, deși linia este de obicei completă în sine. Câmpul via apare doar când nucleul predă pachetul unei adrese de următorul salt; o rută legată de o interfață ajunge la destinațiile sale prin rezolvare la nivelul legăturii sau printr-un partener punct-la-punct. Citirea coloanelor de la stânga la dreapta îți spune în ce caz te afli, iar acea citire ar trebui să aibă loc înainte ca cineva să editeze o rută implicită. Majoritatea tichetelor despre o poartă lipsă se termină la această distincție.

Citește o linie de rută coloană cu coloană

Fiecare intrare începe cu destinația și lungimea prefixului ei, apoi adaugă modificatori într-un vocabular fix: via, dev, proto, scope, src și metric. O linie ca 198.51.100.0/24 dev tun0 proto kernel scope link src 198.51.100.2 este densă, dar complet specificată. Nu îi lipsește nimic și nu se subînțelege nicio adresă de router.

Partea interesantă este absența lui via. Fără un salt următor, nucleul rezolvă destinația direct pe interfața numită, ceea ce pentru un tunel înseamnă predarea cadrului dispozitivului de tunel și lăsarea încapsulării să preia de acolo. proto kernel înregistrează că intrarea a fost instalată automat când a fost atribuită o adresă, nu tastată de un administrator. scope link spune că destinația este accesibilă pe acea legătură fără a trece printr-un router, iar src numește adresa pe care nucleul o va prefera ca sursă pentru traficul care se potrivește.

Acum citește o rută implicită în același fel: default via 192.0.2.254 dev eth0 proto static metric 100. Aici via este prezent pentru că pachetul chiar are nevoie de un salt următor, iar acel salt trebuie să fie el însuși accesibil pe eth0. Cele două linii nu sunt variante una a celeilalte; răspund la întrebări diferite despre unde merge traficul.

Două forme de rută care se confundă între ele

O rută de subrețea de tunel și o rută implicită arată similar într-o captură de ecran și se comportă complet diferit. Folosește tabelul de mai jos ca ajutor de citire pentru câmpuri, apoi confirmă numerele reale pe mașina pe care o depanezi în loc să te bazezi pe un exemplu dintr-un ghid.

Piece of the lineWhat it settlesWhat it says nothing about
The destination and maskWhich packets are eligible to matchWhere those packets leave the host
via plus its addressWhich next hop receives them, and therefore that a router is involvedWhether that router is reachable or sane
devWhich interface carries the encapsulated or raw packetWhether the interface is up or has a carrier
proto and scopeWho installed the entry and how far the destination is considered to beWhether a firewall later drops the traffic

Ceea ce tabelul nu îți poate spune este intenția. O rută directă către un interval privat printr-un tunel este un proiect deliberat de tunel divizat; aceeași formă pe un host care ar trebui să trimită totul prin VPN este un simptom. Intenția trăiește în configurația care a produs intrarea, așa că uită-te la instrumentul care a instalat-o înainte de a concluziona că nucleul a greșit ceva.

La fel, o poartă lipsă nu este permisiunea de a inventa una. Dacă o rută are într-adevăr nevoie de un salt următor, acel salt trebuie să fie accesibil pe interfața care îl transportă, iar pentru un tunel punct-la-punct adresa partenerului nu este același obiect ca adresa locală. A trata adresa locală a tunelului ca pe un router Ethernet este o modalitate obișnuită de a produce o rută care pare corectă și nu transmite nimic.

Întreabă nucleul ce linie va folosi de fapt

Citirea tabelului nu este același lucru cu efectuarea căutării, pentru că nucleul consultă reguli de politică, mai multe tabele și intrări din cache înainte de a răspunde. Verbul care efectuează căutarea reală este ip route get, și tipărește ruta pe care ar lua-o un pachet cu acele proprietăți.

ip route get 203.0.113.37 from 198.51.100.2 iif tun0

Înlocuiește cu destinația care te interesează cu adevărat, apoi adaugă from sau iif când traficul este selectat după sursă sau redirecționat, pentru că o căutare locală obișnuită poate alege o cale diferită de cea a unui client redirecționat. Răspunsul numește interfața, adresa sursă aleasă și orice salt următor, ceea ce este aceeași informație cu care un pachet ar fi rutat în acel moment.

Dacă răspunsul te surprinde, tipărește regulile înainte de a schimba ceva: ip -4 rule show le listează în ordinea priorității, iar un client VPN care instalează propriul tabel sau o regulă pentru pachetele marcate nu va apărea deloc în tabelul principal. Listarea tuturor tabelelor închide acel gol.

ip -4 route show table all | grep -E 'tun|default'

Verifică stratul de sub el înainte de a înlocui ruta implicită

Pachetele tunelului însuși trebuie să ajungă la punctul final îndepărtat, iar asta se face prin interfața fizică folosind ruta care exista înainte de ridicarea VPN-ului. Înlocuirea întregii rute implicite fără fixarea acelui punct final trimite pachetele încapsulate în tunelul pe care ar trebui să îl construiască, iar conexiunea se prăbușește. Confirmă mai întâi calea către punctul final printr-o căutare doar a adresei acestuia.

Ține trei lucruri separate când faci schimbarea: ruta către punctul final care trebuie să rămână pe interfața fizică, intervalele private care ar trebui să intre în tunel și ruta implicită care decide restul. Desparte-le în această ordine, aplică una pe rând și rulează din nou căutarea după fiecare pas. Un ping eșuat după aceea demonstrează foarte puțin în sine, pentru că permisiunile, rutarea răspunsurilor, DNS și serviciul însuși stau toate în aval de o rută corectă.

Notează cele patru valori pe care ți le-a dat linia înainte de editare: destinație, salt următor sau absența lui, dispozitiv și sursa aleasă. Dacă o schimbare ulterioară mută vreunul dintre ele, știi care decizie a fost schimbată de fapt și poți restaura o singură intrare în loc să ghicești întregul tabel.

Articole similare