pfSense OpenVPN: een netwerk achter een andere router bereiken

Je laptop bereikt het pfSense-LAN via de VPN en slaagt er nog steeds niet in om een dienst twee hops verder naar binnen te bereiken, en het verschil is één routingbeslissing per eigenaar. Drie apparaten moeten het eens zijn voordat een pakket zijn heen-en-terugreis voltooit: de client, de firewall en de router die het bestemmingsnetwerk werkelijk bezit. Mis er één en het symptoom ziet er identiek uit.

Volg één pakket door die drie beslissingen voordat je een regel wijzigt, want elke eigenaar heeft een andere controle en een andere faalmodus.

Eén pakket, drie routingbeslissingen

De client beslist of de bestemming bij de tunnel hoort, en kan alleen beslissen op basis van wat hij weet: een gepushte route, een lokale route of een standaardroute die al alles dekt. pfSense beslist waar het pakket hierna heen gaat, wat voor een netwerk achter een andere router een statische route betekent via een bereikbare gateway op de juiste interface. De router beneden beslist of hij een weg terug naar de VPN-pool kent, en zo niet, wordt het antwoord weggegooid of naar een nutteloze plek gestuurd. Elke beslissing staat los van de andere twee.

Het falen van een van hen levert hetzelfde gebruikersrapport op. Daarom is de volgorde van debuggen belangrijker dan de hulpmiddelen.

Geef de client een prefix, geen gok

Op een pfSense SSL/TLS-server met een IPv4-tunnelnetwerk groter dan een /30 verdeelt het veld IPv4 Local network(s) routes naar clients wanneer ze verbinden. Voeg daar de downstream-prefix toe in plaats van erop te vertrouwen dat de client er zelf een verzint. Lees daarna de werkelijke tabel van de client na het verbinden, want een profiel met route-nopull of een routefilter kan negeren wat de server heeft gestuurd. De server kan volkomen correct zijn terwijl de client niets installeert.

Andere servermodi en topologieën hebben andere grenzen, en beleid per client of verbinding kan veranderen wat een specifieke client ontvangt. Controleer op de client die ertoe doet, niet op degene die je toevallig eerst testte.

Wijs pfSense naar de interne router

Een statische route in pfSense vereist een gedefinieerde en bereikbare gateway, en de interface die voor die gateway wordt gekozen moet degene zijn die hem werkelijk bereikt, zoals de Netgate-gids voor statische routes beschrijft. In een illustratieve opstelling is de transitlink 192.168.77.1 op de firewall en 192.168.77.2 op de interne router, met het servicenetwerk op 172.16.30.0/25 erachter. De route noemt dan de prefix en de volgende hop, niet het serviceadres. Een adres uit het verre netwerk als gateway gebruiken is een gangbare manier om een route te bouwen die er correct uitziet en nergens heen doorstuurt.

Een interface een naam geven beschrijft de netwerken erachter niet. De statische route is die beschrijving.

De verre kant moet de pool kennen

De router beneden heeft een retourroute voor de pool nodig, in dit voorbeeld 10.55.0.0/24 via 192.168.77.1, tenzij een standaardroute of een dynamisch protocol er al een biedt. De gateway van de servicehost zelf moet naar die router leiden, wat meestal waar is wanneer de router zijn standaardgateway is en onwaar wanneer de host handmatig is geconfigureerd. Policy-routing op de firewall kan de tabel voor specifiek verkeer ook overschrijven, dus controleer of een regel een andere gateway selecteert voordat je concludeert dat de route fout is.

Voor dit ontwerp is geen vertaling nodig, en de bronadres van de client zichtbaar houden laat het netwerk beneden zijn eigen beleid toepassen.

Voor acceptatie volg je één nieuw verzoek door de tunnelingang, de interne uitgang van de firewall en het antwoord van de bestemming. Als in plaats daarvan bewust vertaling wordt gebruikt, leg dan vast welke bron het netwerk beneden ziet en hoe het antwoord geacht wordt terug te komen.

Bewaar het plan van de drie eigenaren naast de toegestane applicatie, zodat de volgende beheerder het pad kan reconstrueren in plaats van het opnieuw te ontdekken.