Copierea /32 a tunelului nu rutează subrețeaua biroului
Adresa pe care VPN-ul o dă adaptorului descrie legătura, nu destinația. Adăugați prefixul resursei la profil și lăsați ruta implicită în pace.
VPN-ul se conectează, interfața arată o adresă cu o mască de treizeci și doi de biți, iar serverul biroului rămâne inaccesibil. Următorul pas este adesea reutilizarea acelei măști într-o rută, pe teoria că interfața descrie ce poate atinge tunelul. Nu descrie. Acea adresă descrie capătul local al unei legături punct-la-punct, iar destinația care vă interesează se află într-un alt prefix de cealaltă parte.
Se confundă două lucruri diferite: adresa pe care v-a dat-o tunelul și rețeaua la care vreți să ajungeți prin el.
Două adrese, două sarcini
Într-un tunel punct-la-punct, adresa clientului este adesea o singură adresă de gazdă, pentru că la celălalt capăt al legăturii există exact un partener. Nu există segment partajat și nici ARP, așa că o mască ce ar părea absurdă pe Ethernet este aici perfect normală.
Prefixul destinației este un fapt despre rețeaua biroului, nu despre tunel. Dacă aveți nevoie de un server, ruta este o rută de gazdă pentru acel server. Dacă aveți nevoie de întreaga subrețea a biroului, ruta este subrețeaua. Niciunul dintre cele două răspunsuri nu poate fi citit de pe interfață, iar alegerea unuia pentru că a apărut lângă adresa tunelului este felul în care o configurație funcțională se strică.
| What you need to reach | What to install |
|---|---|
| One server, nothing else | A host route for that address |
| The office subnet | A route for the subnet prefix |
| Everything in the private space | Only if the requirement says so, and only with the owner's approval |
Acest al treilea rând este locul unde optimismul devine întrerupere. Rutarea unei întregi game private într-un tunel care deservește un singur sit împinge trafic nelegat pe o cale care nu îl poate livra, iar defecțiunile rezultate arată ca un VPN stricat, nu ca o rută prea largă.
Alegeți prefixul din cerință
Scrieți cerința ca o propoziție înainte de a atinge un profil: ce gazde trebuie să fie accesibile și care este cel mai îngust prefix care le acoperă? Un singur server este o rută de gazdă. O subrețea este o rută de subrețea. O gamă de subrețele este un rezumat, iar un rezumat este o promisiune că fiecare adresă din interior este accesibilă, ceea ce este rareori adevărat.
Apoi verificați numărul față de ceea ce biroul folosește de fapt. Copierea unui prefix dintr-un mesaj de chat fără a-l confirma cu planul de adresare al sitului este felul în care o rută ajunge să indice o subrețea pe care nimeni nu o deține.
Amintiți-vă și că o rută este o cale, nu o permisiune. Gateway-ul decide în continuare dacă clientul dumneavoastră poate folosi destinația, iar un serviciu vă poate încă refuza. Instalarea corectă a rutei aduce pachetul acolo și nu răspunde nimic despre autorizare.
Adăugați la profil, nu îl înlocuiți niciodată
Rutele dintr-un profil NetworkManager sunt o proprietate cu mai multe valori, iar diferența dintre a seta și a adăuga este un singur caracter. Folosiți forma cu plus pentru a adăuga o intrare și a păstra tot ce este deja salvat.
nmcli connection modify uuid 11111111-2222-4333-8444-555555555555 \
+ipv4.routes "10.40.20.9/32"
Fără plus, atribuirea înlocuiește întreaga listă. Pe un profil care poartă deja mai multe prefixe, aceasta șterge în tăcere cele care funcționau, iar simptomul apare mai târziu ca un serviciu care era anterior accesibil de pe acest laptop.
Folosiți UUID în locul numelui. Numele sunt duplicate după restaurări, iar conexiunea pe care o editați poate să nu fie cea care vă transportă traficul. Verificați mai întâi dacă există o intrare identică, pentru că adăugarea unui duplicat este dezordonată chiar și atunci când este inofensivă.
A referința proprietăților de rută documentează destinația, următorul salt opțional, metrica și sintaxa atributelor pentru versiunea instalată. Citiți-o înainte de a adăuga un următor salt, pentru că dacă este necesar depinde de integrare și de topologie, iar ghicirea lui din prima adresă dintr-o listă de interfețe nu este o metodă.
Ruta implicită și DNS sunt decizii separate
Adding an office prefix says nothing about where the rest of your traffic goes. If policy requires ordinary internet traffic to stay outside the tunnel, that is the ipv4.never-default decision, and it belongs to whoever owns the connection policy rather than to whoever is fixing one unreachable server.
Rutele automate sunt celălalt lucru care nu trebuie deranjat cu ușurință. Suprimarea lor pentru a rezolva o intrare lipsă poate elimina mai multe care funcționează, iar persoana care a sugerat asta se uita de obicei la un alt profil, cu alte push-uri.
DNS-ul are propria cale și propriile defecțiuni. Un nume care se rezolvă la adresa corectă prin resolver-ul greșit, sau un resolver care nu poate răspunde pentru zona privată, va arăta ca o problemă de rutare în timp ce ruta este perfectă. Testați adresa și numele separat, apoi decideți care strat a eșuat de fapt.
Verificați ce a fost aplicat
O modificare salvată nu este o modificare aplicată. Reconectați-vă prin ciclul de viață acceptat al managerului, apoi priviți ruta reală către destinația dorită și regulile de politică ce decid ce tabel este consultat.
Dacă prefixul există și conexiunea tot eșuează, ați trecut la altă problemă: selecția adresei sursă, o rută de întoarcere la capătul îndepărtat sau un serviciu care vă refuză clientul. Fiecare dintre acestea este un loc mai bun de privit decât profilul pe care l-ați corectat deja.