pfSense OpenVPN: nå et nettverk bak en annen ruter

Den bærbare datamaskinen din når pfSense-LAN-et over VPN-et og klarer fortsatt ikke å nå en tjeneste to hopp lenger inn, og forskjellen er én rutebeslutning per eier. Tre enheter må bli enige før en pakke fullfører reisen fram og tilbake: klienten, brannmuren og ruteren som faktisk eier destinasjonsnettverket. Mangler én av dem, ser symptomet identisk ut.

Følg én pakke gjennom de tre beslutningene før du endrer en regel, fordi hver eier har en annen kontroll og en annen feilmodus.

Én pakke, tre rutebeslutninger

Klienten avgjør om destinasjonen hører til i tunnelen, og den kan bare avgjøre ut fra det den vet: en skubbet rute, en lokal rute eller en standardrute som allerede dekker alt. pfSense avgjør hvor pakken skal sendes videre, som for et nettverk bak en annen ruter betyr en statisk rute gjennom en nåbar gateway på riktig grensesnitt. Ruteren nedenfor avgjør om den kjenner en vei tilbake til VPN-poolen, og hvis ikke, blir svaret forkastet eller sendt et ubrukelig sted. Hver beslutning er uavhengig av de to andre.

Svikt i én av dem gir samme brukerrapport. Derfor betyr feilsøkingsrekkefølgen mer enn verktøyene.

Gi klienten et prefiks, ikke en gjetning

På en pfSense SSL/TLS-server med et IPv4-tunnelnettverk større enn et /30 fordeler feltet IPv4 Local network(s) ruter til klientene når de kobler til. Legg til det nedre prefikset der i stedet for å stole på at klienten finner på ett. Les deretter klientens faktiske tabell etter tilkobling, fordi en profil med route-nopull eller et rutefilter kan ignorere det serveren sendte. Serveren kan være helt korrekt mens klienten ikke installerer noe.

Andre servermoduser og topologier har andre grenser, og policy per klient eller tilkobling kan endre hva en bestemt klient mottar. Verifiser på klienten som betyr noe, ikke på den du tilfeldigvis testet først.

Pek pfSense mot den interne ruteren

En statisk rute i pfSense trenger en gateway som er definert og nåbar, og grensesnittet som velges for den gatewayen, må være det som faktisk når den, slik Netgates veiledning for statiske ruter beskriver. I et illustrerende oppsett er transittlenken 192.168.77.1 på brannmuren og 192.168.77.2 på den interne ruteren, med tjenestenettverket på 172.16.30.0/25 bak. Ruten navngir da prefikset og neste hopp, ikke tjenesteadressen. Å bruke en adresse fra det fjerne nettverket som gateway er en vanlig måte å bygge en rute som ser riktig ut og ikke videresender noe sted.

Å gi et grensesnitt et navn beskriver ikke nettverkene bak det. Den statiske ruten er den beskrivelsen.

Den fjerne siden må kjenne poolen

Ruteren nedenfor trenger en returrute for poolen, i dette eksempelet 10.55.0.0/24 via 192.168.77.1, med mindre en standardrute eller en dynamisk protokoll allerede gir en. Gatewayen til tjenestehoster selv må lede mot den ruteren, noe som vanligvis er sant når ruteren er standardgatewayen, og usant når hosten ble konfigurert manuelt. Policy-ruting på brannmuren kan også overstyre tabellen for bestemt trafikk, så sjekk om en regel velger en annen gateway før du konkluderer med at ruten er feil.

Ingen oversettelse er nødvendig for denne utformingen, og å holde klientens kildeaddresse synlig lar det nedre nettverket bruke sin egen policy.

For aksept, følg én ny forespørsel gjennom tunellinngangen, brannmurens interne utgang og svaret fra destinasjonen. Hvis oversettelse i stedet brukes bevisst, noter hvilken kilde det nedre nettverket ser og hvordan svaret forventes å komme tilbake.

Lagre planen med de tre eierne sammen med den tillatte applikasjonen, slik at neste administrator kan gjenoppbygge stien i stedet for å oppdage den på nytt.