Reguli VPN pe router: potrivește sursa și destinația
O regulă VPN pe router are două capete: dispozitivul care trimite trafic și destinația care trebuie să folosească tunelul. Stabilește mai întâi intersecția și comportamentul de rezervă.
Paginile de cumpărare a routerelor prezintă rutarea VPN ca o singură casetă de selectare, iar formularea ascunde trei întrebări diferite. Regula se potrivește cu dispozitivul care trimite traficul, cu serverul care îl primește sau cu ambele? Ce se întâmplă cu traficul care nu se potrivește cu niciunul? Și când două reguli se suprapun, care câștigă? Scrierea răspunsului ca pereche de sursă și destinație transformă o listă vagă de funcții într-un design care poate fi testat.
Numele funcției ascunde două capete
Un player media care ar trebui să folosească tunelul este o potrivire de sursă. Un prefix de birou privat care ar trebui să fie accesibil prin tunel este o potrivire de destinație. O stație de lucru care ar trebui să folosească tunelul doar pentru un serviciu este ambele, iar acea intersecție este cazul pe care majoritatea firmware-ului de consum îl gestionează prost.
Scrie cerința ca pereche înainte de a compara produse. Acea pereche este ceea ce vei testa mai târziu.
Un produs care oferă o listă de dispozitive sau o listă globală de destinații poate să nu poată exprima „doar acest dispozitiv, doar aceste destinații”. Diferența nu este cosmetică: o regulă globală de destinație trimite traficul fiecărui dispozitiv către acel site prin tunel, iar o regulă de dispozitiv trimite tot traficul acelui dispozitiv. Niciuna nu este cerința. Testează acel caz cu două dispozitive înainte să ai încredere în ecran.
Construiește regula ca intersecție
Un tabel ține designul onest. Pune scenariul în stânga, apoi numește separat potrivirea expeditorului și potrivirea țintei:
| Scenario | Sender match | Target match | Rule shape |
|---|---|---|---|
| Media player uses the tunnel | Player address | Any internet destination except the LAN | Source only |
| Office prefix reachable | Authorized LAN devices | 10.40.0.0/16 | Target only |
| One app on one laptop | Laptop address | The service address set | Source and target |
| Guest network never tunnels | Guest subnet | Any | Deny, evaluated first |
Al treilea rând este cel interesant, pentru că are nevoie de ambele jumătăți simultan. Dacă firmware-ul poate exprima doar o singură axă, cerința trebuie împărțită în două reguli sau mutată pe un dispozitiv care poate face asta.
Păstrează identitatea sursei stabilă. O rezervare DHCP, un segment dedicat sau un mecanism de identitate a dispozitivului funcționează, dar o adresă care se schimbă după expirarea închirierii nu. Include IPv6, pentru că o adresă IPv4 nu identifică tot traficul unui dispozitiv.
Prioritatea decide suprapunerea
Suprapunerea regulilor este normală. O regulă largă de dispozitiv și una îngustă de destinație pot descrie același flux, iar ordinea de prioritate documentată decide care câștigă. Un ecran de setări atractiv nu îți spune acea ordine.
Citește manualul pentru ordine și pentru cazul fără potrivire, apoi testează ambele cu trafic pe care îl poți observa:
ip rule show
ip route get 203.0.113.10
Dacă documentația nu precizează ordinea, presupune că regula mai îngustă poate să nu câștige și proiectează ținând cont de asta. Două reguli care nu pot intra în conflict sunt mai ușor de susținut decât o singură regulă deșteaptă cu precedență nedocumentată.
Numele au nevoie de o politică de reîmprospătare
O destinație scrisă ca domeniu adaugă o problemă de mentenanță. Routerul trebuie să o rezolve, să reîmprospăteze maparea, să gestioneze mai multe adrese și subdomenii și să facă față DNS-ului aplicațiilor care ocolește resolverul așteptat.
Copierea unui singur rezultat de căutare într-o regulă IP este o instantanee, nu o politică de domeniu.
Decide cât de vechi poate fi un răspuns înainte ca regula să fie greșită și ce face routerul când rezolvarea eșuează. O regulă care păstrează ultima adresă cunoscută poate supraviețui unei migrări de serviciu; o regulă care aruncă intrarea poate opri în tăcere tunelarea. Ambele comportamente sunt acceptabile dacă sunt notate lângă regulă.
Definește starea indisponibilă
O preferință de rută nu impune trafic doar prin VPN. Când tunelul este oprit, routerul poate bloca fluxul, îl poate trimite direct sau poate folosi alt tunel, iar fiecare alegere are o semnătură de eșec diferită.
Decide de care are nevoie cerința, apoi verifică oprind tunelul și urmărind fluxul:
curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://service.example/
ping -c 2 203.0.113.10
Traficul originat de routerul însuși este un domeniu separat. Redirecționarea DNS, verificările de actualizare și monitorizarea pot porni fluxuri noi chiar de la router, în loc să moștenească potrivirea de sursă a dispozitivului. Ia în calcul explicit acele fluxuri, altfel vor apărea ca scurgeri neexplicate în jurnale.