pfSense OpenVPN: nå eit nettverk bak ein annan ruttar

Den berbare datamaskinen din når pfSense-LAN-et over VPN-et og klarar framleis ikkje å nå ei teneste to hopp lenger inn, og skilnaden er éi rutingsavgjerd per eigar. Tre einingar må bli samde før ein pakke fullfører reisa fram og tilbake: klienten, brannmuren og ruttaren som faktisk eig målnettverket. Manglar éin av dei, ser symptomet identisk ut.

Følg éin pakke gjennom dei tre avgjerdene før du endrar ei regel, fordi kvar eigar har ein annan kontroll og ein annan feilmodus.

Éin pakke, tre rutingsavgjerder

Klienten avgjer om målet høyrer til i tunnelen, og kan berre avgjere ut frå det han veit: ei dytta rute, ei lokal rute eller ei standardrute som allereie dekkjer alt. pfSense avgjer kvar pakken skal sendast vidare, som for eit nettverk bak ein annan ruttar tyder ei statisk rute gjennom ein nåbar gateway på rett grensesnitt. Ruttaren nedanfor avgjer om han kjenner ein veg tilbake til VPN-bassenget, og viss ikkje, blir svaret kasta eller sendt ein ubrukeleg stad. Kvar avgjerd er uavhengig av dei to andre.

Svikt i éin av dei gjev same brukarrapport. Difor tyder feilsøkingsrekkjefølgja meir enn verktya.

Gjev klienten eit prefiks, ikkje ei gjetting

På ein pfSense SSL/TLS-tenar med eit IPv4-tunnelnettverk større enn eit /30 fordeler feltet IPv4 Local network(s) ruter til klientane når dei koplar til. Legg til det nedre prefikset der i staden for å stole på at klienten finn på eit. Les så den faktiske tabellen til klienten etter tilkopling, fordi ein profil med route-nopull eller eit rutefilter kan ignorere det tenaren sende. Tenaren kan vere heilt korrekt medan klienten ikkje installerer noko.

Andre tenarmodusar og topologiar har andre grenser, og policy per klient eller tilkopling kan endre kva ein bestemd klient mottek. Stadfest på klienten som tyder noko, ikkje på den du tilfeldigvis testa først.

Peik pfSense mot den interne ruttaren

Ei statisk rute i pfSense treng ein gateway som er definert og nåbar, og grensesnittet som blir valt for den gatewayen, må vere det som faktisk når han, slik Netgate si rettleiing for statiske ruter skildrar. I eit illustrerande oppsett er transitlenka 192.168.77.1 på brannmuren og 192.168.77.2 på den interne ruttaren, med tenestenettverket på 172.16.30.0/25 bak. Ruta namngjev då prefikset og neste hopp, ikkje tenesteadressa. Å bruke ei adresse frå det fjerne nettverket som gateway er ein vanleg måte å byggje ei rute som ser rett ut og ikkje videresender nokon stad.

Å gje eit grensesnitt eit namn skildrar ikkje nettverka bak det. Den statiske ruta er den skildringa.

Den fjerne sida må kjenne bassenget

Ruttaren nedanfor treng ei returrute for bassenget, i dette dømet 10.55.0.0/24 via 192.168.77.1, med mindre ei standardrute eller ein dynamisk protokoll allereie gjev ei. Gatewayen til tenestehosten sjølv må leie mot den ruttaren, noko som vanlegvis er sant når ruttaren er standardgatewayen, og usant når hosten vart konfigurert manuelt. Policy-ruting på brannmuren kan også overstyre tabellen for bestemd trafikk, så sjekk om ei regel vel ein annan gateway før du konkluderer med at ruta er feil.

Ingen omsetjing er nødvendig for denne utforminga, og å halde kjeldeadressa til klienten synleg lèt det nedre nettverket nytte sin eigen policy.

For aksept, følg éin ny førespurnad gjennom tunellinngangen, den interne utgangen til brannmuren og svaret frå målet. Viss omsetjing i staden blir brukt med vilje, noter kva kjelde det nedre nettverket ser og korleis svaret er venta å kome tilbake.

Lagre planen med dei tre eigarane saman med den tillatne applikasjonen, slik at neste administrator kan byggje opp att stien i staden for å oppdage han på nytt.