VPN Pi cu mai multe routere: pune fiecare rută pe dispozitivul care decide
Un router din aval adaugă o a doua subrețea de clienți, iar fiecare dintre cele patru dispozitive deține o decizie. Pune rutele, verifică sursa, apoi testează de pe un client real.
Punerea unei cutii Wi-Fi în spatele Pi transformă o decizie de rutare în patru, iar planul se rupe când toate patru sunt luate pe un singur dispozitiv. Prima întrebare nu este ce rută să adaugi. Este dacă noua cutie face punte sau rutează, pentru că acel răspuns decide câte subrețele există și ce dispozitive trebuie să învețe despre ele. Alege mai întâi modelul de conectare; fiecare rută decurge din el.
Punte sau rutare: alegerea care stabilește numărul
O punte pune clienții noi în aceeași subrețea pe care Pi o deservește deja. O subrețea, o autoritate DHCP și nicio predare de rutat. Aceasta este aranjamentul mai simplu și cel corect când o rețea de clienți separată nu a fost niciodată o cerință. O legătură rutată este un alt proiect: cutia își păstrează propria subrețea, iar acel prefix trebuie dus peste tot unde merge traficul.
Restul planului păstrează routerul din aval și protejează adresele de sursă ale clienților. Ținta este o rețea VPN privată, nu o ieșire completă în internet. Scrie modelul înaintea adreselor, pentru că lista de mai jos este doar un exemplu de conectare rutată.
client subnet 10.41.0.0/24
client gateway 10.41.0.1
router-to-Pi link 192.168.71.2
Pi on that link 192.168.71.1
private target 10.72.9.0/24Cine decide ce
| Decision owner | Entry that encodes the decision | Failure when the entry is missing |
|---|---|---|
| Pi VPN host | Return route for 10.41.0.0/24 via 192.168.71.2, and a tunnel route for 10.72.9.0/24 | Replies to downstream clients die at the Pi |
| Owner of the remote network | A path for 10.41.0.0/24 over the permitted tunnel | Replies stop at the first unaware hop |
| LAN router behind the Pi | Specific route for 10.72.9.0/24 via 192.168.71.1, or a suitable default | Clients never send private traffic to the Pi |
| Client machine | Default via 10.41.0.1, or a specific entry for 10.72.9.0/24 | The private network is unreachable from the client |
Fiecare dispozitiv ia o decizie, iar niciunul nu o poate lua pe a altuia în locul lui. Pi are nevoie de două intrări, nu de una, iar calea de întoarcere este cea pe care oamenii o uită. Traficul redirecționat ajunge corect la rețeaua privată și apoi moare la întoarcere, pentru că Pi nu are nicio idee unde locuiește 10.41.0.0/24. Asta pare o problemă de firewall și este de fapt o rută lipsă.
Și partea îndepărtată are nevoie de propria rută. Dacă serviciul de la capătul îndepărtat nu știe că 10.41.0.0/24 este accesibil prin tunelul tău, răspunsurile se opresc la primul salt fără răspuns. Adaugă ambele direcții înainte de a citi filtrele de pachete.
Următoarele salturi vin din conectare
Următorul salt trebuie să fie o adresă într-o rețea pe care dispozitivul o poate atinge cu adevărat. Adresa publică a partenerului VPN nu este următorul salt pentru o subrețea privată, iar rețeaua de servicii îndepărtată nu este deloc un următor salt. O rută către o poartă de acces inaccesibilă pare corectă într-o listă și aruncă fiecare pachet. Verifică dacă poarta de acces răspunde înainte de a da vina pe destinație.
Menține partenerul VPN exterior al Pi accesibil prin propria sa rută de nivel inferior. Acea intrare este separată de rutele de încărcătură utilă, iar amestecarea lor dă un tunel care nu se poate restabili după o schimbare de cale.
Documentația despre rute statice face clară distincția între destinație și poartă de acces, deși fiecare platformă își numește meniurile diferit. Citește documentația dispozitivului din fața ta în loc să copiezi ecranul altui furnizor. Comenzile de mai jos arată forma intrărilor în Linux.
# on the Pi
ip route add 10.41.0.0/24 via 192.168.71.2
ip route add 10.72.9.0/24 dev tun0
# on the downstream router
ip route add 10.72.9.0/24 via 192.168.71.1Ce face traducerea cu sursa
Dacă routerul din aval își traduce deja clienții la adresa de tranzit, Pi vede o singură sursă tradusă în locul adresei proprii a fiecărui client. Acesta este un proiect diferit de cel care păstrează sursa de mai sus. Schimbă politica bazată pe sursă, jurnalizarea și care parte poate iniția conexiuni. Ambele proiecte funcționează; răspund la întrebări diferite.
Când un serviciu VPN din amonte refuză să ruteze prefixul clientului înapoi, o traducere îngustă la ieșirea tunelului Pi poate fi o soluție legitimă. Nu este dovada că ruta lipsă era inutilă. Notează ce adresă vede de fapt rețeaua îndepărtată și ce cale de întoarcere rezultă.
Selectarea rutei, permisiunea de redirecționare și traducerea sursei rămân trei sarcini separate. Golirea unui lanț NAT partajat sau permiterea fiecărei interfețe pentru că un client cu cablu funcționează este modul în care un test funcțional devine un redirector deschis.
Demonstrează asta de pe o mașină client
Trimite o cerere de pe o mașină din LAN-ul din aval, apoi urmărește-i sursa afară și înapoi. Un ping emis de Pi nu exersează niciodată ruta de întoarcere din aval, de aceea un ping reușit dovedește mai puțin decât pare. Adaugă un al doilea test de pe un client cu cablu în LAN-ul propriu al Pi, ca cele două căi să poată fi comparate. Repetă ambele după repornirea oricăruia dintre dispozitive.
Rutele adăugate manual și traducerile care nu au fost niciodată salvate dispar împreună. Atunci perechea pare o defecțiune nouă în loc de muncă neterminată.
Salvează modelul de conectare împreună cu rutele, serviciul privat permis și orice traducere într-o singură notă. Acea notă este ce îl împiedică pe următorul om să trateze plasarea wireless ca pe o chestiune de politică de rutare.