pfSense OpenVPN: ajungerea la o rețea din spatele altui router

Laptopul tău ajunge la LAN-ul pfSense prin VPN și tot nu reușește să ajungă la un serviciu cu două hopuri mai adânc, iar diferența este o decizie de rutare pentru fiecare proprietar. Trei dispozitive trebuie să fie de acord înainte ca un pachet să își încheie drumul dus-întors: clientul, firewallul și routerul care deține efectiv rețeaua de destinație. Dacă lipsește oricare dintre ele, simptomul arată identic.

Urmărește un pachet prin aceste trei decizii înainte de a schimba o regulă, pentru că fiecare proprietar are un alt control și un alt mod de defectare.

Un pachet, trei decizii de rutare

Clientul decide dacă destinația aparține tunelului și poate decide doar pe baza a ceea ce știe: o rută împinsă, o rută locală sau o rută implicită care acoperă deja totul. pfSense decide unde să trimită pachetul mai departe, ceea ce pentru o rețea din spatele altui router înseamnă o rută statică printr-un gateway accesibil pe interfața corectă. Routerul de jos decide dacă știe o cale înapoi la pool-ul VPN, iar dacă nu știe, răspunsul este aruncat sau trimis într-un loc inutil. Fiecare decizie este independentă de celelalte două.

Defectarea oricăreia dintre ele produce același raport al utilizatorului. De aceea ordinea de depanare contează mai mult decât instrumentele.

Dă clientului un prefix, nu o presupunere

Pe un server pfSense SSL/TLS cu o rețea de tunel IPv4 mai mare decât un /30, câmpul IPv4 Local network(s) distribuie rute către clienți când se conectează. Adaugă prefixul din aval acolo în loc să te bazezi pe client să inventeze unul. Apoi citește tabelul real al clientului după conectare, pentru că un profil cu route-nopull sau un filtru de rute poate ignora ce a trimis serverul. Serverul poate fi perfect corect în timp ce clientul nu instalează nimic.

Alte moduri de server și topologii au limite diferite, iar politica pentru fiecare client sau conexiune poate schimba ce primește un anumit client. Verifică pe clientul care contează, nu pe cel pe care l-ai testat primul din întâmplare.

Îndreaptă pfSense spre routerul intern

O rută statică în pfSense are nevoie de un gateway definit și accesibil, iar interfața aleasă pentru acel gateway trebuie să fie cea care ajunge efectiv la el, așa cum descrie ghidul Netgate pentru rute statice. Într-o configurare ilustrativă, legătura de tranzit este 192.168.77.1 pe firewall și 192.168.77.2 pe routerul intern, cu rețeaua de servicii la 172.16.30.0/25 în spate. Ruta numește apoi prefixul și următorul hop, nu adresa serviciului. Folosirea unei adrese din rețeaua îndepărtată ca gateway este o modalitate obișnuită de a construi o rută care pare corectă și nu trimite nicăieri.

Darea unui nume unei interfețe nu descrie rețelele din spatele ei. Ruta statică este acea descriere.

Partea îndepărtată trebuie să cunoască pool-ul

Routerul de jos are nevoie de o rută de întoarcere pentru pool, în acest exemplu 10.55.0.0/24 prin 192.168.77.1, dacă o rută implicită sau un protocol dinamic nu oferă deja una. Gateway-ul gazdei serviciului însuși trebuie să ducă spre acel router, ceea ce este de obicei adevărat când routerul este gateway-ul implicit și fals când gazda a fost configurată manual. Rutarea bazată pe politici de pe firewall poate și ea să suprascrie tabelul pentru trafic anume, așa că verifică dacă o regulă selectează alt gateway înainte de a concluziona că ruta este greșită.

Acest design nu necesită traducere, iar păstrarea vizibilă a adresei sursă a clientului permite rețelei din aval să aplice propria politică.

Pentru acceptare, urmărește o cerere nouă prin intrarea tunelului, ieșirea internă a firewallului și răspunsul de la destinație. Dacă în schimb se folosește deliberat traducerea, notează ce sursă vede rețeaua din aval și cum se așteaptă să revină răspunsul.

Salvează planul celor trei proprietari lângă aplicația permisă, astfel încât următorul administrator să poată reconstrui calea în loc să o descopere din nou.