Cum să dai unei rețele LAN de test propriul punct de ieșire WireGuard

Trei proiecte rezolvă aceeași problemă de laborator: o rețea LAN mică trebuie să iasă printr-un partener WireGuard, în timp ce poarta însăși își păstrează legătura obișnuită către exterior. Scurtătura tentantă este să muți ruta implicită a routerului în tunel, dar asta rupe calea de administrare a cutiei și tot ce redirecționează ea. Opțiunea interesantă este rutarea bazată pe politici, limitată la o singură interfață și un singur prefix. Alege între ele răspunzând la trei întrebări despre mașina pe care o ai cu adevărat.

Decide unde locuiește ieșirea

Prima întrebare: această gazdă redirecționează și pentru altceva? O poartă de laborator dedicată poate trăi cu o politică de redirecționare care aruncă totul implicit. Un router cu atribuții de producție nu poate, iar suprapunerea unui set concurent de reguli peste un firewall administrat este exact felul în care se programează întreruperile. A doua: poți deține două obiecte de politică și ordinea lor peste reporniri? A treia: partenerul pe care îl ai autorizează adresa sursă a tunelului și oferă ieșire spre internet? Un partener care expune doar o rețea privată este alt produs, și nicio modificare locală de rutare nu rezolvă asta. Dacă orice răspuns este nu, pune ieșirea într-un spațiu de nume sau într-o mașină virtuală de unică folosință.

Un spațiu de nume sau o VM costă memorie și îți dă o rază de impact curată. Rutarea bazată pe politici costă două reguli și îți lasă o singură cutie de depanat.

Alege ieșirea care îți autorizează sursa

Majoritatea eșecurilor din acest laborator se întâmplă înainte să existe măcar o regulă de firewall. Operatorul ieșirii trebuie să accepte adresa sursă pe care o poartă pachetele tale după traducere, iar în acest proiect aceea este adresa tunelului, nu prefixul LAN. De aceea mascarea face parte din proiect încă de la început, nu ca adaos târziu.

Confirmă trei lucruri cu operatorul: partenerul autorizează adresa tunelului tău, redirecționează IPv4 în loc să se termine în el însuși și aplică NAT de ieșire. Fără primul, pachetele tale ajung și dispar. Fără al treilea, pleacă cu o sursă privată și mor la următorul salt. Apoi verifică faptul că wg-quick nu instalează propria rută implicită, ceea ce Table = off împiedică; acea setare suprimă crearea de rute, nu verificările AllowedIPs ale partenerului sau tratarea DNS de către acesta.

Două obiecte de politică fac dirijarea

Dirijarea are nevoie de un tabel și de o regulă. Tabelul ține două rute: prefixul LAN ieșind din interfața LAN și o rută implicită ieșind din tunel. Regula trimite în tabel traficul care sosește pe interfața LAN și poartă acel prefix. Folosește selectorul iif împreună cu potrivirea sursei, fiindcă pachetele WireGuard ale porții apar local și nu se potrivesc niciodată cu o interfață de intrare.

Paznicul vine înaintea căutării, nu după ea. Această ordine este întreaga proprietate de siguranță a proiectului.

Paznicul este o a doua regulă pe același selector, al cărei verdict este unreachable. Dă-i o prioritate numerică mai mare ca să câștige în continuare căutarea cât timp tunelul este ridicat. Când ruta tunelului dispare, căutarea nu întoarce nimic, iar paznicul oprește căutarea în loc să o lase să cadă pe ruta implicită WAN din tabelul principal.

ip rule add from 192.168.50.0/24 iif lan0 lookup 51861 pref 1000
ip rule add from 192.168.50.0/24 iif lan0 unreachable pref 1001
ip route add table 51861 default dev wg0

Închide golul de repliere înainte să îl deschizi

Instalează mai întâi paznicul și apoi căutarea. Făcut invers, rămâne o fereastră de câteva secunde în care traficul unui client de test poate ajunge la legătura către exterior.

Filtrul completează tabloul. În cârligul forward acceptă direcția de la LAN spre tunel pentru prefixul de test și direcția de retur stabilită, apoi aruncă tot restul; NAT-ul pentru acel prefix pe interfața tunelului merge în postrouting. Tocmai lăsarea policy drop pe lanțul de redirecționare este ce transformă o rută lipsă în tăcere în loc de scurgere. Filtrarea căii inverse are nevoie de modul relaxat pe interfața tunelului, fiindcă o sursă publică ce sosește decapsulată are cea mai bună rută inversă pe partea WAN. Linux ia valoarea mai mare dintre all și cea pe interfață, deci setarea interfeței tunelului nu este același lucru cu slăbirea validării peste tot.

Demonstrează cu cazul de eșec

Pune nucleului o întrebare precisă, numind adresa sursă a clientului și interfața pe care sosește. O căutare fără ambele răspunde la altă întrebare și va părea corectă în ambele cazuri. Apoi uită-te la contoarele firewallului, la starea de transfer a partenerului și la serviciul clientului însuși.

Testează corect eliminarea. Oprește tunelul lăsând regula și filtrul la locul lor: clientul ar trebui să se blocheze, iar traficul propriu al porții ar trebui să continue să funcționeze. Apoi oprește partenerul fără să atingi interfața locală, iar acesta este cazul care prinde proiectele ce se bazează doar pe existența rutei. În final repornește și reverifică ordinea regulilor, fiindcă un cârlig de demontare care scoate paznicul dă întregul proiect înapoi tabelului principal. Notează numărul tabelului, prioritățile și numele interfețelor pe tichetul de modificare, fiindcă următoarea persoană care adaugă o regulă este cea care va strica asta.