Router VPN: LAN și WAN — ce trebuie notat înainte de cumpărare
O etichetă VPN nu spune nimic despre VLAN-uri, comutarea la eroare WAN sau rolurile tunelurilor. Notați capacitățile exacte ale modelului și firmware-ului pe care intenționați să îl implementați.
Tratați eticheta pregătit pentru VPN ca pe o singură caracteristică a unui echipament care trebuie să și ruteze, să segmenteze și să comute la eroare, fiindcă eticheta nu spune nimic despre câte rețele separate poate găzdui dispozitivul. Începeți prin a scrie un registru de capacități pentru modelul și firmware-ul exacte, apoi comparați acel registru cu fluxurile de care are nevoie locația. Paginile de marketing enumeră mufe; rareori enumeră apartenența la VLAN, politica de comutare la eroare sau domeniul tunelului. Registrul durează aproximativ douăzeci de minute și rezolvă majoritatea disputelor de cumpărare înainte de sosirea hardware-ului.
Fixați echipamentul exact înainte de orice altceva
Numele modelelor călătoresc între generații de firmware, iar aceeași carcasă poate fi livrată cu un driver de comutator diferit în funcție de versiune. Citiți identitatea plăcii de pe dispozitivul însuși, nu de pe cutie, astfel încât fiecare afirmație ulterioară să fie legată de ceva ce puteți reproduce. O singură comandă acoperă modelul, numele plăcii și versiunea de firmware în OpenWrt, iar ecranele echivalente există în majoritatea firmware-urilor de business.
ssh [email protected] 'ubus call system board'
cat /etc/openwrt_release
Scrieți acele șiruri în registru, niciodată abreviate. Apoi separați sarcina obișnuită de rutare de sarcina tunelului. Un dispozitiv care redirecționează bine pachetele poate refuza totuși să încheie un tunel, iar un dispozitiv care încheie un tunel poate să nu aibă cum să țină două rețele locale separate. Dacă ambele sunt tratate ca o singură cerință, nepotrivirea se ascunde până când unitatea este deja montată în rack, configurată și pe jumătate de încredere.
Notați structura LAN, nu numărul de porturi
Patru mufe înseamnă de obicei un singur comutator, iar un comutator înseamnă un singur domeniu de difuzare dacă nu sunt configurate VLAN-uri. Este potrivit pentru o rețea de domiciliu plată și greșit pentru un sediu care vrea un segment pentru oaspeți, un segment de administrare și un segment de camere izolat pe același echipament. Notați ce porturi aparțin cărui VLAN, ce VLAN-uri ajung la procesor și ce interfețe poartă adrese.
Acolo unde firmware-ul oferă VLAN-uri, lista de interfețe decide câte politici distincte puteți scrie. Un VLAN definit pe comutator dar niciodată atribuit ca interfață nu are adresă și nu are zonă de firewall, așa că nu poate impune nimic singur.
| Field to record | Example entry | Review stops if |
|---|---|---|
| Ports and VLAN membership | ports 1-4 untagged on VLAN 10, port 5 trunk with VLAN 10 and 20 | the datasheet offers only a socket count |
| Routed interfaces | br-lan 192.168.88.1/24, vlan20 192.168.99.1/24 | two subnets cannot hold separate policies |
| WAN method and failover | DHCP on wan, PPPoE on wan2, policy route to wan2 on loss | only one uplink is configurable |
| Tunnel role and scope | WireGuard peer on the router, only 192.168.88.0/24 routed inside | the router can only pass another tunnel through |
Citiți starea comutatorului în loc să vă încredeți în meniu. Pe ținte OpenWrt mai vechi unealta de comutator tipărește dispozitivele configurate, iar pe ținte DSA uneltele de punte raportează aceleași fapte pentru fiecare port, de aceea versiunea de firmware aparține registrului.
Notați comportamentul WAN și al comutării la eroare
Metoda de acces, proprietatea adresei și ordinea de comutare la eroare stau pe o singură linie pentru fiecare legătură ascendentă, fiindcă un tunel care supraviețuiește unei schimbări de WAN depinde de toate trei. O sesiune PPPoE se reconectează cu o adresă nouă și dărâmă tunelul odată cu ea, în timp ce o legătură DHCP care își păstrează bailul poate să nu facă asta.
Comutarea la eroare cere și o decizie de politică. Trimiterea întregului trafic pe legătura de rezervă este ușoară; păstrarea tunelului pe legătura principală în timp ce traficul web obișnuit folosește rezerva cere rutare bazată pe politică, și nu toate firmware-urile o oferă. Notați dacă tunelul este legat de o singură legătură ascendentă și ce face dispozitivul cu sesiunile stabilite când acea legătură dispare. Păstrați tabela de rutare ca dovadă, nu bifa de comutare la eroare.
Testați un flux permis și un flux interzis
Registrul merită păstrat doar dacă dispozitivul poate fi acceptat pe baza lui. Alegeți un flux care trebuie să funcționeze, unul care nu trebuie, și rulați ambele de la un client din segmentul respectiv. Un tunel care transportă fiecare subrețea este un eșec când cerința era o singură subrețea.
Apoi confirmați interdicția, fiindcă o valoare implicită permisivă este surpriza obișnuită. Segmentul pentru oaspeți nu trebuie să ajungă la adresa de administrare, iar verificarea ar trebui să arate un timeout sau un refuz, nu o pagină de autentificare.
curl -sS --max-time 8 https://api.ipify.org
ping -c 2 192.168.99.1
ip -4 route get 192.168.99.1
Dacă fluxul permis funcționează și cel interzis la fel, segmentarea lipsește chiar dacă meniurile sugerau altceva. Dacă ambele eșuează, domeniul tunelului sau calea de întoarcere sunt greșite, iar registrul WAN explică de obicei care. Păstrați cele două rezultate împreună cu registrul de capacități, pentru ca următorul recenzent să vadă ce s-a acceptat, pe ce firmware și la ce dată.