pfSense OpenVPN: atingi reton malantaŭ alia enkursigilo

Via tekkomputilo atingas la pfSense-LAN per la VPN kaj tamen malsukcesas atingi servon du saltetojn pli interne, kaj la diferenco estas unu enkursiga decido por posedanto. Tri aparatoj devas konsenti antaŭ ol paketo finos sian tien-reen vojaĝon: la kliento, la fajroŝirmilo kaj la enkursigilo, kiu fakte posedas la celan reton. Manku iu ajn el ili kaj la simptomo aspektas idente.

Spuru unu paketon tra tiuj tri decidoj antaŭ ol ŝanĝi regulon, ĉar ĉiu posedanto havas alian regilon kaj alian fiaskmanieron.

Unu paketo, tri enkursigaj decidoj

La kliento decidas ĉu la celo apartenas al la tunelo, kaj ĝi povas decidi nur el tio, kion ĝi scias: puŝita itinero, loka itinero aŭ defaŭlta itinero, kiu jam kovras ĉion. pfSense decidas kien sendi la paketon poste, kio por reto malantaŭ alia enkursigilo signifas statikan itineron tra atingebla pordego sur la ĝusta interfaco. La malsupra enkursigilo decidas ĉu ĝi konas vojon reen al la VPN-naĝejo, kaj se ne, la respondo estas forĵetita aŭ sendita al senutila loko. Ĉiu decido estas sendependa de la aliaj du.

La fiasko de iu ajn el ili produktas la saman raporton de la uzanto. Tial la ordo de sencimigado pli gravas ol la iloj.

Donu al la kliento prefikson, ne konjekton

Sur pfSense SSL/TLS-servilo kun IPv4-tunela reto pli granda ol /30, la kampo IPv4 Local network(s) disdonas itinerojn al klientoj kiam ili konektiĝas. Aldonu la malsupran prefikson tie anstataŭ fidi, ke la kliento elpensos unu. Poste legu la faktan tabelon de la kliento post konektiĝo, ĉar profilo kun route-nopull aŭ itinera filtrilo povas ignori tion, kion la servilo sendis. La servilo povas esti tute ĝusta dum la kliento instalas nenion.

Aliaj servilaj reĝimoj kaj topologioj havas aliajn limojn, kaj politiko por kliento aŭ konekto povas ŝanĝi tion, kion ricevas specifa kliento. Kontrolu sur la kliento, kiu gravas, anstataŭ sur tiu, kiun vi hazarde unue testis.

Direktu pfSense al la interna enkursigilo

Statika itinero en pfSense bezonas pordegon difinitan kaj atingeblan, kaj la interfaco elektita por tiu pordego devas esti tiu, kiu fakte atingas ĝin, kiel priskribas la gvidilo de Netgate pri statikaj itineroj. En ilustra aranĝo la traira ligilo estas 192.168.77.1 sur la fajroŝirmilo kaj 192.168.77.2 sur la interna enkursigilo, kun la serva reto ĉe 172.16.30.0/25 malantaŭ ĝi. La itinero tiam nomas la prefikson kaj la sekvan salteton, ne la servan adreson. Uzi adreson el la fora reto kiel pordegon estas ofta maniero konstrui itineron, kiu aspektas ĝusta kaj plusendas nenie.

Doni nomon al interfaco ne priskribas la retojn malantaŭ ĝi. La statika itinero estas tiu priskribo.

La fora flanko devas koni la naĝejon

La malsupra enkursigilo bezonas revenan itineron por la naĝejo, en ĉi tiu ekzemplo 10.55.0.0/24 tra 192.168.77.1, krom se defaŭlta itinero aŭ dinamika protokolo jam provizas unu. La pordego de la servo-gastiganto mem devas konduki al tiu enkursigilo, kio kutime veras kiam la enkursigilo estas ĝia defaŭlta pordego kaj malveras kiam la gastiganto estis permane agordita. Politika enkursigado sur la fajroŝirmilo ankaŭ povas transpasi la tabelon por specifa trafiko, do kontrolu ĉu regulo elektas alian pordegon antaŭ ol konkludi, ke la itinero malĝustas.

Neniu traduko necesas por ĉi tiu dezajno, kaj teni la fontan adreson de la kliento videbla permesas al la malsupra reto apliki sian propran politikon.

Por akcepto, spuru unu novan peton tra la tunela enirejo, la interna elirejo de la fajroŝirmilo kaj la respondo de la celo. Se anstataŭe oni intence uzas tradukon, notu, kiun fonton la malsupra reto vidas kaj kiel oni atendas, ke la respondo revenos.

Konservu la planon de la tri posedantoj apud la permesita aplikaĵo, por ke la sekva administranto povu rekonstrui la vojon anstataŭ remalkovri ĝin.