Ghid OPNsense: Smart Routing prin ASN și Failover WireGuard

În prima parte a ghidului am configurat accesul de bază: eu intru acasă securizat (Admin), iar prietenii ies pe internet prin IP-ul meu (Guest). Dar ce facem când blocajele devin agresive? Recent, filtrele pentru competițiile sportive au început să blocheze indiscriminat clase întregi de IP-uri (vedeți Cloudflare vs. La Liga), afectând site-uri legitime care nu au nicio legătură cu pirateria.

Soluția mea la această problemă este Smart Routing-ul bazat pe ASN, dublat de un sistem de Failover robust între două locații diferite (București și Cluj). Practic, vom transforma OPNsense într-un router care „știe” să ocolească blocajele automat, doar pentru traficul afectat, lăsând restul internetului (Netflix, YouTube, Amazon) să meargă direct prin fibra locală (PPPoE), cu viteză maximă și latență minimă.

Arhitectura Soluției

Vom adăuga două noi conexiuni WireGuard (client) către două locații externe (București și Cluj). Vom instrui OPNsense să detecteze automat traficul destinat Cloudflare sau Digi (folosind ASN-uri, nu liste manuale de IP-uri care se schimbă constant) și să îl ruteze prin VPN. Dacă tunelul principal (Cluj) pică, traficul va trece automat pe cel secundar (București).

Variabile Noi

• WG_Cluj (Tier 1): Tunelul primar.
• WG_Bucuresti (Tier 2): Tunelul de rezervă (Failover).
• ASN-uri Țintă: Cloudflare (13335), RCS-RDS (8708), Orange/Telekom (9050).

Pasul 1: Configurarea Clienților WireGuard (Tunelurile)

Presupunem că aveți deja serverele WireGuard configurate în locațiile remote. În OPNsense-ul local, procesul este următorul:

1. Mergeți la VPN » WireGuard » Instances și adăugați două instanțe noi (inclusiv Peers, pentru izolare) pentru WG_Cluj și WG_Bucuresti, apoi asociați-le.
2. Salvați și asigurați-vă că tunelurile sunt „Up” (Handshake realizat). Fără handshake, nu putem trece mai departe.

Pasul 2: Interfețe și Gateway-uri

Pentru a putea face rutare (Policy Routing), OPNsense trebuie să trateze aceste tuneluri ca pe niște interfețe WAN veritabile.

1. Mergeți la Interfaces » Assignments. Asignați instanțele WireGuard create (ex: wg2 și wg3) unor interfețe noi (ex: opt6, opt7).
2. Denumiți-le sugestiv: WG_Cluj și WG_Bucuresti.
3. Activați interfețele (Enable Interface), dar lăsați IPv4 Configuration pe „None” (sau Static, dacă cere setup-ul vostru specific, dar niciodată DHCP pe interfețe de tunel WG).
4. Mergeți la System » Gateways » Configuration.
   • Adăugați un gateway pentru WG_Cluj.
   • Important: Bifați opțiunea Far Gateway.
   • Setați Monitor IP cu adresa internă a tunelului remote (ex: 10.114.54.1). Acest IP este folosit pentru a detecta dacă tunelul e picat.
   • Repetați procedura pentru WG_Bucuresti.

Foarte Important: Asigurați-vă că gateway-ul vostru principal (WAN_PPPOE) are bifa „Upstream Gateway” activată, iar noile gateway-uri VPN NU o au. Altfel, riscați să trimiteți tot traficul implicit prin VPN, ceea ce nu ne dorim.

Pasul 3: Grupul de Failover (Creierul Operațiunii)

Acum vom crea un grup care gestionează redundanța automată.

1. Mergeți la System » Gateways » Group.
2. Creați un grup nou numit: WG_Cloudflare_Failover.
3. Configurați prioritățile (Tier):
   • WG_Cluj_GW: Tier 1 (Prioritate Maximă).
   • WG_Bucuresti_GW: Tier 2 (Rezervă).
   • WAN_PPPOE: Never (Nu vrem ca acest trafic să iasă neprotejat vreodată).
4. Trigger Level: Member Down.

Pasul 4: Aliases – Puterea BGP ASN

Aici este inovația majoră față de listele clasice de IP-uri. Nu mai vânăm IP-uri manual, ci folosim numerele sistemelor autonome (ASN).

1. Mergeți la Firewall » Aliases.
2. Creați un alias nou: Cloudflare_RCS_RDS.
3. Type: BGP ASN.
4. Content: 8708 (Digi), 9050 (Orange/Telekom), 13335 (Cloudflare).

Safety Net: Creați încă un alias de tip Host(s) numit VPN_Endpoint_Digi care să conțină adresele DDNS ale serverelor VPN (ex: dnsulmeu.go.ro). Vom avea nevoie de el pentru a preveni buclele de rutare (au am mai creat două și pentru acces la rețelele înc are se află serverele WirewGuard, câte una pentru fiecare, utilizate în reguli LAN separate).

Dacă tot ce urmăriți e să deviați un trafic specific printr-un tunel WireGuard, aliasul Cloudflare_RCS_RDS e singura de care veți avea nevoie.

Pasul 5: Regulile de Firewall (Logica de Rutare)

Ordinea regulilor în Firewall » Rules » LAN este critică. Dacă greșiți ordinea, tot sistemul cade.

1. Block IPv6 to ASN: Blocați traficul IPv6 către alias-ul Cloudflare_RCS_RDS. Motivul? Tunelurile noastre sunt IPv4, și vrem să forțăm clienții să facă fallback pe IPv4 pentru aceste destinații.
2. Bypass VPN for Tunnel Endpoints: O regulă Pass către VPN_Endpoint_Digi care folosește gateway-ul WAN_PPPOE.
   • De ce? Fără asta, tunelul VPN ar încerca să se conecteze la serverul din Cluj trecând… prin tunelul către Cluj. O buclă infinită care dărâmă conexiunea.
3. Acces Rețele Remote: Permiteți accesul către rețelele LAN din Cluj/București prin gateway-urile specifice (opțional, doar dacă faceți administrare remote).
4. Policy Routing (Regula Magică):
   • Proto: IPv4.
   • Destination: Cloudflare_RCS_RDS (Alias-ul ASN creat anterior).
   • Gateway: WG_Cloudflare_Failover (Grupul creat la pasul 3).
   • Această regulă „prinde” tot traficul către furnizorii afectați și îl aruncă în tunel.
5. Default Allow: Regula standard care lasă restul traficului (Google, Facebook, Work) să iasă prin default (PPPoE).

Pasul 6: Outbound NAT

Dacă traficul intră pe tunel, trebuie să și poată ieși pe internet la capătul celălalt.

1. Mergeți la Firewall » NAT » Outbound.
2. Asigurați-vă că sunteți pe modul Hybrid.
3. Adăugați câte o regulă manuală pentru fiecare interfață VPN (WG_Cluj și WG_Bucuresti):
   • Source: LAN sau ANY.
   • Translation: Interface address.

Fără aceste reguli, pachetele ajung la Cluj, dar serverul de acolo nu știe unde să trimită răspunsul.

Pasul 7: Mentenanță și Stabilitate

Pentru ca totul să ruleze în regim „set and forget”, trebuie să ne asigurăm că DNS-ul nu ne joacă feste.

• Cron Job pentru DNS: Conexiunile pe IP dinamic (DDNS) pot rămâne blocate dacă IP-ul serverului se schimbă. Mergeți la System » Settings » Cron și adăugați un job: Renew DNS for WireGuard on stale connections la fiecare 5 minute.

Concluzie

Configurând routerul astfel, ideal ar fi ca atunci când deschideți Digi Online pe TV, traficul spre serverele Digi să treacă automat prin VPN, iar site-urile protejate de Cloudflare să foe accesate ocolind blocajele La Liga. Mai mult, dacă unul dintre serverele WireGuard pică, traficul este deviat instat prin celălalt. În tot acest timp, restul site-urilor și serviciilor ar trebui să iasă pe Internet direct prin WAN, fără a fi afectate de latența unui VPN, însă:

inetnum:        188.26.192.0 - 188.26.199.255
geoloc:         40.533792 -3.627541
netname:        ES-RESIDENTIAL
descr:          DIGI Spain Telecom
org:            ORG-DSTS3-RIPE
country:        ES
language:       ES
admin-c:        RDS-RIPE
tech-c:         RDS-RIPE
tech-c:         RDS2012-RIPE
status:         ASSIGNED PA
mnt-by:         AS8708-MNT
mnt-lower:      AS8708-MNT
created:        2019-08-06T12:07:49Z
last-modified:  2021-12-21T08:34:05Z
source:         RIPE # Filtered

Fiind presat de timp, am apelat la o soluție provizorie, ca un un „Dorel” autentic, doar ca să văd sistemul funcțional pe moment.

Am descoperit între timp o metodă mult mai elegantă și aparent definitivă, bazată pe AdGuard, Dnsmasq și wildcard domain, dar și una în jurul claselor de IP. Le voi testa pe ambele pentru a decide care este mai fiabilă.

Apropo de latență, un detaliu tehnic important: dacă la Trigger Level alegeți opțiunea Packet Loss and High Latency, comutarea de pe un tunel pe altul se va face instantaneu, imediat ce latența depășește limitele configurate.

Deși sună bine în teorie, practic poate genera o problemă de tip „ping-pong” (o buclă de comutări repetate), mai ales atunci când latențele fluctuează sau sunt ridicate pe ambele conexiuni. Pentru a evita acest comportament instabil, recomandarea mea este să activați neapărat și opțiunea Sticky Connections.