Client OpenVPN pentru întregul LAN pe OpenWrt: o ordine de lucru

Patru sarcini independente aduc tot LAN-ul unui router în spatele unui singur tunel. Dispozitivul tunelului are nevoie de un proprietar, de o zonă de firewall, de o țintă de traducere spre uplink și, dacă unii clienți trebuie să rămână în afara VPN-ului, de rutare după adresa sursă. Un tunel care se conectează în timp ce nimic nu trece are de obicei una dintre cele patru lipsă. Lucrul în ordinea dependențelor înseamnă că un eșec la final aparține pasului pe care tocmai l-ai schimbat. Fiecare pas de mai jos se termină cu ceva ce poți observa, ceea ce împiedică pasul următor să fie o presupunere.

Decide ce împarte tunelul

Routerul care distribuie Wi-Fi și DHCP poate rula clientul singur. Asta pune fiecare dispozitiv conectat în spatele tunelului fără configurare per dispozitiv, și este aranjamentul pe care majoritatea siturilor mici îl vor. Este și cel cu cel mai mare impact când tunelul cade, pentru că fiecare dispozitiv își pierde calea deodată. Nimic din LAN nu păstrează o rută de ieșire funcțională.

Un al doilea router în spatele primului, care rulează clientul cu propria subrețea, limitează tunelul la dispozitivele sale. Este mai ușor de eliminat și mai ușor de explicat celui care îl moștenește. Costul este accesibilitatea între cele două părți fără o rută sau un port forward.

Într-un fel sau altul, fă subrețelele LAN distincte. Intervalele identice fac o parte să pară conectată direct, și gaura neagră rezultată se citește ca o defecțiune VPN ore întregi.

Dă tunelului un proprietar

Declară tunelul ca interfață de rețea cu un nume, un dispozitiv și fără protocol propriu. Sistemul de rețea creează și administrează apoi dispozitivul, iar tot ce urmează se referă la interfață prin nume, nu prin dispozitiv. Asta îi permite zonei să îl găsească.

Nu crea același dispozitiv în două locuri. Un tunel făcut manual lângă o interfață declarată produce un dispozitiv care există dar nu e în nicio zonă, sau unul care dispare la reîncărcare. Ambele arată ca o defecțiune a clientului, și niciunul nu produce o eroare care să numească cauza reală. Alege calea declarativă și șterge-o pe cea manuală.

Păstrează numele identic în configurația de rețea, de firewall și de VPN. Zona listează rețelele după nume, așa că o greșeală de tastare lasă tunelul în afara oricărei zone în timp ce interfața în sine pare sănătoasă. O interfață sănătoasă fără politică este starea cea mai greu de observat.

Pune-l într-o zonă, apoi redirecționează în ea

O zonă de firewall este locul unde stă politica: intrare, ieșire, redirecționare și masquerade. Un tunel fără zonă este guvernat de valori implicite pe care nu le-ai ales, ceea ce rareori este ce are nevoie un client de router. Blocurile de mai jos declară interfața, o pun într-o zonă și permit traficului LAN să intre în acea zonă.

config interface 'vpn'
    option device 'tun0'
    option proto 'none'

config zone
    option name 'vpn'
    list network 'vpn'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option masq '1'

config forwarding
    option src 'lan'
    option dest 'vpn'

Pe versiunile mai vechi decât 21.02 aceeași linie de interfață se scrie ca option ifname, deci verifică ce formă interpretează firmware-ul instalat înainte de a lipi. Blocul de redirecționare este permisiunea care lasă traficul LAN să folosească tunelul. Fără el dispozitivul este pornit, clientul este conectat, și niciun host din LAN nu ajunge la tunel. Este cea mai frecventă reclamație de conectat dar fără internet la clienții de router.

Masquerade pe zona VPN colapsează fiecare adresă LAN în adresa de tunel a routerului înainte ca pachetul să plece. Asta elimină nevoia unei rute de întoarcere către subrețeaua ta pe partea cealaltă.

Dacă partea cealaltă deja rutează LAN-ul tău, oprirea masquerade-ului păstrează adresele sursă vizibile și face logurile per client semnificative. Alege una și notează care, pentru că cele două variante produc întrebări de suport diferite mai târziu. Eliminarea redirecționării implicite LAN-spre-WAN este o decizie separată cu consecința ei. Scoate-o și accesul la internet al routerului însuși pleacă împreună cu ea.

Numește uplink-ul real în NAT

Pe firmware-ul unde regula de traducere este scrisă manual, interfața de ieșire este câmpul care se strică. O regulă care numește vlan2 nu face nimic când sesiunea se termină pe ppp0. O regulă fără nicio interfață poate traduce trafic care ar fi trebuit să rămână privat. Niciuna dintre greșeli nu se anunță, pentru că tunelul continuă să funcționeze.

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

Înlocuiește ppp0 din acea regulă cu interfața din ip route sau din lista interfețelor active, apoi urmărește contorul în timp ce un host LAN încarcă o pagină. Pe un router cu un singur furnizor, o regulă de masquerade pentru uplink este de obicei suficientă. O a doua regulă pentru interfața tunelului nu este un substitut pentru prima.

Apoi adaugă opțiunile de client care decid ce intră în tunel. O directivă redirect-gateway trimite traficul de internet al clientului prin VPN, iar fără ea tunelul transportă doar rutele împinse de server. Verifică tabela de rute rezultată înainte de a atinge DNS-ul.

Împarte Wi-Fi-ul cu o a doua tabelă

O tabelă de rutare nu poate ține două valori implicite. Un al doilea SSID care trebuie să ocolească tunelul are deci nevoie de propria subrețea și propria tabelă. Dă SSID-ului tunelat propriul interval, apoi rutează doar acel interval în tunel cu o regulă care selectează tabela.

Pachetele de rutare pe politică din OpenWrt exprimă exact acea combinație. Se poate face și manual, cu o regulă de sursă și o tabelă al cărei implicit indică dispozitivul tunelului.

Verifică împărțirea din ambele rețele. Un client pe SSID-ul tunelat trebuie să prezinte adresa de ieșire a VPN-ului, iar un client pe SSID-ul obișnuit adresa furnizorului. Când ambele arată la fel, regula se potrivește cu sursa greșită sau tabela nu este consultată niciodată. Testează și după o reconectare, pentru că o regulă dependentă de numele interfeței se rupe când dispozitivul primește un număr nou.

Suspectează ceasul și flag-ul dispozitivului

Flag-ul persist-tun lasă dispozitivul tunelului pe loc între reporniri. Asta se potrivește unui server și încurcă un client a cărui stare trebuie reconstruită de la zero. Scoate-l cât depanezi un client de router, pentru că un dispozitiv care supraviețuiește unei negocieri eșuate ascunde care pas s-a stricat de fapt. Pune-l la loc după ce clientul se conectează fiabil, și nu înainte.

Ceasul este cealaltă defecțiune tăcută. Un router fără ceas cu baterie pornește de la epocă, ceea ce înseamnă că verificările de certificat eșuează până când NTP ajunge din urmă. Compară marcajele de timp din log cu timpul real înainte de a atinge un certificat, pentru că un client care se conectează la un minut după boot de obicei așteaptă sincronizarea timpului.