pfSense OpenVPN: nå ett nätverk bakom en annan router

Din bärbara dator når pfSense-LAN:et via VPN:et och lyckas ändå inte nå en tjänst två hopp längre in, och skillnaden är ett routingbeslut per ägare. Tre enheter måste komma överens innan ett paket slutför sin resa fram och tillbaka: klienten, brandväggen och routern som faktiskt äger destinationsnätet. Saknas någon av dem ser symptomet identiskt ut.

Följ ett paket genom de tre besluten innan du ändrar en regel, eftersom varje ägare har en annan kontroll och ett annat feltillstånd.

Ett paket, tre routingbeslut

Klienten avgör om destinationen hör till tunneln, och kan bara avgöra utifrån det den vet: en pushad rutt, en lokal rutt eller en standardrutt som redan täcker allt. pfSense avgör vart paketet ska skickas härnäst, vilket för ett nätverk bakom en annan router innebär en statisk rutt via en nåbar gateway på rätt gränssnitt. Routern nedanför avgör om den känner till en väg tillbaka till VPN-poolen, och om inte kastas svaret eller skickas någonstans utan nytta. Varje beslut är oberoende av de andra två.

Fel i något av dem ger samma användarrapport. Därför betyder felsökningsordningen mer än verktygen.

Ge klienten ett prefix, inte en gissning

På en pfSense SSL/TLS-server med ett IPv4-tunnelnätverk större än ett /30 distribuerar fältet IPv4 Local network(s) rutter till klienterna när de ansluter. Lägg till det nedre prefixet där i stället för att lita på att klienten hittar på ett. Läs sedan klientens faktiska tabell efter anslutningen, eftersom en profil med route-nopull eller ett ruttfilter kan ignorera det servern skickade. Servern kan vara helt korrekt medan klienten inte installerar något.

Andra serverlägen och topologier har andra gränser, och policy per klient eller anslutning kan ändra vad en viss klient tar emot. Verifiera på klienten som betyder något, inte på den du råkade testa först.

Peka pfSense mot den interna routern

En statisk rutt i pfSense kräver en definierad och nåbar gateway, och gränssnittet som väljs för den gatewayen måste vara det som faktiskt når den, som Netgates guide för statiska rutter beskriver. I en illustrativ uppställning är transitlänken 192.168.77.1 på brandväggen och 192.168.77.2 på den interna routern, med tjänstenätet på 172.16.30.0/25 bakom. Rutten namnger då prefixet och nästa hopp, inte tjänstens adress. Att använda en adress från fjärrnätet som gateway är ett vanligt sätt att bygga en rutt som ser korrekt ut och inte vidarebefordrar någonstans.

Att ge ett gränssnitt ett namn beskriver inte nätverken bakom det. Den statiska rutten är den beskrivningen.

Fjärrsidan måste känna till poolen

Routern nedanför behöver en returrutt för poolen, i detta exempel 10.55.0.0/24 via 192.168.77.1, om inte en standardrutt eller ett dynamiskt protokoll redan ger en. Gatewayen för själva tjänstevärden måste leda mot den routern, vilket vanligtvis är sant när routern är dess standardgateway och falskt när värden konfigurerades manuellt. Policy-routing på brandväggen kan också åsidosätta tabellen för viss trafik, så kontrollera om en regel väljer en annan gateway innan du drar slutsatsen att rutten är fel.

Ingen översättning krävs för den här designen, och att hålla klientens källadress synlig låter det nedre nätverket tillämpa sin egen policy.

För acceptans, följ en ny begäran genom tunnelns ingång, brandväggens interna utgång och svaret från destinationen. Om översättning i stället används medvetet, anteckna vilken källa det nedre nätverket ser och hur svaret förväntas komma tillbaka.

Spara planen med de tre ägarna bredvid den tillåtna applikationen, så att nästa administratör kan återskapa vägen i stället för att upptäcka den igen.