pfSense OpenVPN: arritja e një rrjeti pas një routeri tjetër

Laptopi juaj arrin LAN-in e pfSense përmes VPN-së dhe prapë nuk arrin një shërbim dy hop më thellë, dhe ndryshimi është një vendim rrugëtimi për çdo pronar. Tre pajisje duhet të bien dakord përpara se një paketë të përfundojë udhëtimin vajtje-ardhje: klienti, firewalle dhe routeri që zotëron vërtet rrjetin e destinacionit. Nëse mungon ndonjëri prej tyre, simptoma duket identike.

Ndiqni një paketë nëpër këto tre vendime përpara se të ndryshoni një rregull, sepse çdo pronar ka një kontroll tjetër dhe një mënyrë tjetër dështimi.

Një paketë, tre vendime rrugëtimi

Klienti vendos nëse destinacioni i përket tunelit dhe mund të vendosë vetëm nga ajo që di: një rrugë e shtyrë, një rrugë lokale ose një rrugë e paracaktuar që tashmë mbulon gjithçka. pfSense vendos ku ta dërgojë paketën më pas, që për një rrjet pas një routeri tjetër do të thotë një rrugë statike përmes një portë të arritshme në ndërfaqen e saktë. Routeri poshtë vendos nëse njeh një rrugë kthimi te pishina e VPN-së, dhe nëse nuk njeh, përgjigja hidhet ose dërgohet diku pa dobi. Çdo vendim është i pavarur nga dy të tjerët.

Dështimi i secilit prej tyre jep të njëjtin raport të përdoruesit. Prandaj rendi i korrigjimit ka më shumë rëndësi se mjetet.

Jepini klientit një prefiks, jo një hamendje

Në një server pfSense SSL/TLS me një rrjet tuneli IPv4 më të madh se /30, fusha IPv4 Local network(s) shpërndan rrugë te klientët kur ata lidhen. Shtoni atje prefiksin e poshtëm në vend që të mbështeteni te klienti që të shpikë një. Më pas lexoni tabelën reale të klientit pas lidhjes, sepse një profil me route-nopull ose një filtër rrugësh mund të injorojë atë që dërgoi serveri. Serveri mund të jetë plotësisht i saktë ndërsa klienti nuk instalon asgjë.

Mënyrat e tjera të serverit dhe topologjitë kanë kufij të ndryshëm, dhe politika për klient ose lidhje mund të ndryshojë atë që merr një klient i caktuar. Verifikoni në klientin që ka rëndësi, jo në atë që rastësisht e testuat i pari.

Drejtojeni pfSense te routeri i brendshëm

Një rrugë statike në pfSense kërkon një portë të përcaktuar dhe të arritshme, dhe ndërfaqja e zgjedhur për atë portë duhet të jetë ajo që arrin vërtet tek ajo, siç përshkruan udhëzuesi i Netgate për rrugët statike. Në një skemë ilustruese, lidhja e tranzitit është 192.168.77.1 në firewall dhe 192.168.77.2 në routerin e brendshëm, me rrjetin e shërbimeve në 172.16.30.0/25 pas tij. Rruga pastaj emërton prefiksin dhe hopin tjetër, jo adresën e shërbimit. Përdorimi i një adrese nga rrjeti i largët si portë është një mënyrë e zakonshme për të ndërtuar një rrugë që duket e saktë dhe nuk përcjell askund.

T'i japësh një emër ndërfaqes nuk i përshkruan rrjetet pas saj. Rruga statike është ai përshkrim.

Ana e largët duhet ta njohë pishinën

Routeri poshtë ka nevojë për një rrugë kthimi për pishinën, në këtë shembull 10.55.0.0/24 përmes 192.168.77.1, përveç nëse një rrugë e paracaktuar ose një protokoll dinamik siguron tashmë një. Porta e vetë hostit të shërbimit duhet të drejtojë drejt atij routeri, që zakonisht është e vërtetë kur routeri është porta e tij e paracaktuar dhe e rreme kur hosti u konfigurua me dorë. Rrugëtimi me politikë në firewall mund të anashkalojë gjithashtu tabelën për trafik të caktuar, prandaj kontrolloni nëse një rregull zgjedh një portë tjetër përpara se të konkludoni që rruga është e gabuar.

Ky dizajn nuk kërkon përkthim, dhe lënia e dukshme e adresës burimore të klientit i lejon rrjetit poshtë të zbatojë politikën e vet.

Për pranim, ndiqni një kërkesë të re përmes hyrjes së tunelit, daljes së brendshme të firewallit dhe përgjigjes nga destinacioni. Nëse në vend të kësaj përdoret me qëllim përkthimi, shënoni burimin që sheh rrjeti poshtë dhe si pritet të kthehet përgjigja.

Ruani planin e tre pronarëve pranë aplikacionit të lejuar, në mënyrë që administratori tjetër të mund të rindërtojë rrugën në vend që ta zbulojë përsëri.