pfSense OpenVPN: nå et netværk bag en anden router

Din bærbare computer når pfSense-LAN'et over VPN'et og formår stadig ikke at nå en tjeneste to hop længere inde, og forskellen er én routingbeslutning pr. ejer. Tre enheder skal være enige, før en pakke fuldfører sin rejse frem og tilbage: klienten, firewallen og den router, der faktisk ejer destinationsnetværket. Mangler bare én af dem, ser symptomet identisk ud.

Følg én pakke gennem de tre beslutninger, før du ændrer en regel, fordi hver ejer har en anden kontrol og en anden fejltilstand.

Én pakke, tre routingbeslutninger

Klienten afgør, om destinationen hører til i tunnelen, og den kan kun afgøre det ud fra det, den ved: en skubbet rute, en lokal rute eller en standardrute, der allerede dækker alt. pfSense afgør, hvor pakken skal sendes hen næste gang, hvilket for et netværk bag en anden router betyder en statisk rute gennem en nåelig gateway på det korrekte interface. Den nederste router afgør, om den kender en vej tilbage til VPN-poolen, og hvis ikke, bliver svaret droppet eller sendt et ubrugeligt sted hen. Hver beslutning er uafhængig af de to andre.

Svigt af blot én af dem giver samme brugerrapport. Derfor betyder fejlfindingsrækkefølgen mere end værktøjerne.

Giv klienten et præfiks, ikke et gæt

På en pfSense SSL/TLS-server med et IPv4-tunnelnetsværk større end et /30 fordeler feltet IPv4 Local network(s) ruter til klienterne, når de opretter forbindelse. Tilføj det nederste præfiks der i stedet for at stole på, at klienten finder på et. Læs derefter klientens faktiske tabel efter forbindelsen, fordi en profil med route-nopull eller et rutefilter kan ignorere det, serveren sendte. Serveren kan være helt korrekt, mens klienten ikke installerer noget.

Andre servertilstande og topologier har andre grænser, og politik pr. klient eller forbindelse kan ændre, hvad en bestemt klient modtager. Verificér på den klient, der betyder noget, i stedet for på den, du tilfældigvis testede først.

Peg pfSense mod den interne router

En statisk rute i pfSense kræver en gateway, der er defineret og nåelig, og det interface, der vælges til gatewayen, skal være det, der faktisk når den, som Netgates guide til statiske ruter beskriver. I et illustrativt layout er transitforbindelsen 192.168.77.1 på firewallen og 192.168.77.2 på den interne router, mens tjenestenetværket er 172.16.30.0/25 bag den. Ruten angiver derefter præfikset og det næste hop, ikke tjenesteadressen. At bruge en adresse fra det fjerne netværk som gateway er en almindelig måde at bygge en rute, der ser rigtig ud og ikke videresender noget.

At give et interface et navn beskriver ikke netværkene bag det. Den statiske rute er den beskrivelse.

Den fjerne side skal kende poolen

Den nederste router har brug for en returrute til poolen, i dette eksempel 10.55.0.0/24 via 192.168.77.1, medmindre en standardrute eller en dynamisk protokol allerede giver en. Tjenestehostens egen gateway skal føre mod den router, hvilket normalt er sandt, når routeren er dens standardgateway, og falsk, når hosten blev konfigureret manuelt. Policy routing på firewallen kan også tilsidesætte tabellen for bestemt trafik, så tjek, om en regel vælger en anden gateway, før du konkluderer, at ruten er forkert.

Der kræves ingen oversættelse i dette design, og ved at holde klientens kildeaddresse synlig kan det nederste netværk anvende sin egen politik.

Til accept skal du følge én ny anmodning gennem tunnelindgangen, firewallens interne udgang og svaret fra destinationen. Hvis der i stedet bevidst bruges oversættelse, skal du notere, hvilken kilde det nederste netværk ser, og hvordan svaret forventes at komme tilbage.

Gem planen med de tre ejere sammen med den tilladte applikation, så den næste administrator kan genskabe stien i stedet for at opdage den igen.