pfSense als VPN-server en -client: twee paden, één router

Eén apparaat kan tegelijk twee kanten op kijken: roaming-gebruikers verbinden naar binnen, en dezelfde doos verbindt naar buiten met een uitgangsprovider zodat geselecteerd verkeer via een ander netwerk vertrekt. Beide diensten inschakelen kost minuten; ze naast elkaar laten bestaan vraagt een ontwerp, omdat de tweede rol de routetabel herschrijft waarop de eerste leunt. Drie voorwaarden bepalen of de opstelling werkt, namelijk of de inkomende dienst zijn eigen terugweg houdt, of de uitgaande tunnel zijn peer nog bereikt, en of het verkeer dat u wilde doorsturen voor de uitgang wordt geselecteerd. Eén verkeerd en u krijgt twee tunnels die beide verbonden melden terwijl er niets bruikbaars tussen hen oversteekt. De controles hieronder stellen elke voorwaarde vast in de volgorde waarin de storingen gewoonlijk verschijnen.

Benoem de twee rollen voordat u een instelling aanraakt

Noteer vier feiten per instantie: de externe peer, het authenticatiemateriaal, de adrespool die zij uitgeeft en de netwerken erachter. De twee instanties zijn afzonderlijke objecten op het apparaat en moeten dat ook in uw notities blijven. Bijna elk verwarrend symptoom later komt uit het door elkaar halen van hun waarden, en twee instanties die één set notities delen is hoe de verkeerde pool in het verkeerde veld belandt.

De inkomende dienst heeft een tunnelnettwerk nodig dat niet overlapt met de adressen van de uitgaande tunnel of met enig particulier netwerk dat het apparaat routeert. Overlap is de enige fout die in beide rollen tegelijk symptomen geeft, en het is veel goedkoper om die op papier te vangen. Vergelijk beide pools en elk gerouteerd particulier netwerk op één plek voordat u een van de diensten configureert.

Gedeelde hardware betekent niet gedeelde inloggegevens, en een clientcertificaat uit de pool voor externe toegang zou niet bruikbaar moeten zijn tegen de uitgangsprovider. Apart materiaal maakt ook intrekking een lokale beslissing in plaats van een gebeurtenis voor de hele vloot.

Houd de antwoorden van de server op het WAN-pad

De antwoorden die het apparaat zelf genereert, zijn het eerste slachtoffer van een slordige standaardroute. Wanneer het ingekapselde pakket van een roaming-gebruiker aankomt, is het antwoord lokaal ontstaan verkeer en het moet vertrekken via de interface waarlangs die gebruiker binnenkwam. Als de uitgangsclient een standaardroute heeft geïnstalleerd die het onderschept, komt het antwoord in de verkeerde tunnel en stokt de sessie terwijl de dienst er nog gezond uitziet.

Er is geen enkel selectievakje dat dit beslecht, omdat de beslissing gaat over welk verkeer de uitgangsclient mag onderscheppen. Ofwel u trekt geen routes en stuurt alleen wat u selecteert, ofwel u trekt routes en voegt de uitzonderingen toe die de eigen diensten van het apparaat aan de gang houden. Schrijf de keuze naast de instantie, anders zal de volgende persoon de andere aannemen.

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

Lees de routetabel op de langste overeenkomst en niet op de volgorde waarin u iets hebt geconfigureerd. De vraag is welke vermelding wint voor het adres van de uitgangspeer en welke vermelding wint voor het antwoord van de inkomende dienst, en die twee antwoorden kunnen verschillen.

Laat de uitgaande tunnel niet zijn eigen eindpunt opeten

De uitgangsclient moet de openbare adres van zijn peer bereiken om de tunnel überhaupt op te zetten. Als dat adres zelf in de tunnel wordt gerouteerd, jaagt de client zijn eigen staart achterna: het transport komt nooit omhoog, of het komt omhoog en valt op het moment dat de route wordt geïnstalleerd. Het log ziet eruit als een authenticatie-time-out en niet als een routefout, en daarom verdient de route de eerste controle.

Controleer de route vóór de inloggegevens en opnieuw nadat de tunnel omhoog is, omdat een vermelding bij het opstarten juist kan zijn en een minuut later onjuist. Het adres van de peer moet naar het gewone WAN-pad wijzen, nooit naar het tunnelapparaat. Zodra het transport stabiel is, verschuift de interessante vraag naar doorgestuurd verkeer, en dat is de volgende beslissing.

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

Kies welke gebruikers de uitgang krijgen

Bronbeleid hoort bij de ingang waar verkeer het apparaat binnenkomt, dus kies de pool voor externe toegang, of smallere identiteiten daarbinnen. Behoud de particuliere bestemmingen en beheeruitzonderingen die nooit naar de uitgang mogen, en plaats die regels vóór de brede. Het uitgangspad heeft dan zijn eigen vertaling of een gerouteerde terugregeling nodig, wat voor de meeste ontwerpen uitgaande NAT op de uitgangsinterface betekent die de pool dekt. Vertaling kiest geen uitgang; zij herschrijft alleen wat al vertrokken is, dus een NAT-regel op een onbetrokken WAN verandert niets aan de selectie.

Bevestig dat de verte kant doorgestuurd verkeer uit dit ontwerp toestaat, want sommige providers doen dat en andere niet. Het verschil toont zich als een tunnel die verbindt en niets draagt, wat gemakkelijk als een lokale storing te lezen is. Test de drie stromen apart, want ze falen onafhankelijk en twee van de drie is een half gebouwd ontwerp.

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

De eerste opdracht is de buitenste verbinding van de roaming-gebruiker, en die werkt wanneer de client meldt dat de initialisatiereeks voltooid is. De tweede, uitgevoerd vanaf die verbonden laptop, zou het adres van de uitgangsprovider moeten melden in plaats van uw WAN-adres. De derde draait op het apparaat gebonden aan een pooladres, en test het bronbeleid voor doorgestuurd verkeer zonder überhaupt een externe gebruiker te betrekken. Als hij in plaats daarvan uit het WAN antwoordt, paste het beleid niet, en geen enkele NAT-bewerking lost een selectieprobleem op.

Bepaal wat er gebeurt als de uitgang faalt

Schrijf het storingsgedrag op voordat het gebeurt: als de uitgaande tunnel wegvalt, vallen gebruikers dan terug op het gewone WAN of worden ze geblokkeerd tot de uitgang terugkeert? Beide antwoorden zijn verdedigbaar, en het apparaat kiest niet voor u. Een verwijderde route of een beleid dat naar een dode gateway wijst, levert niet automatisch een volledig geblokkeerd resultaat op. Wilt u blokkering, dan moet het beleid dat expliciet zeggen, en het moet getest worden door de uitgang weg te nemen in plaats van erover te redeneren. Wilt u terugval, maak dat dan bekend aan gebruikers, want verkeer dat stil het gewone pad neemt is precies het verkeer waarvan iemand dacht dat het gedekt was.

Schakel de clientinstantie uit, kijk wat een verbonden gebruiker nog bereikt en start hem dan weer. Een verzoek dat afloopt is het volledig geblokkeerde resultaat dat u vroeg; een dat met het WAN-adres antwoordt is de terugval die u niet documenteerde. Herhaal de controle voor IPv6 en voor DNS, omdat een beleid geschreven voor IPv4 niets zegt over AAAA-verkeer en een resolver die door een van de tunnels wordt geduwd antwoordt van waar de query werkelijk vertrekt.

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

Het Netgate-recept voor gerouteerde OpenVPN laat zien hoe bronbeleid, interfacetoewijzing en uitgaande vertaling samengaan, en de site-naar-site-scope is het deel dat niet in zijn geheel moet worden gekopieerd. Wat het u niet zal vertellen, is welke van de drie voorwaarden hierboven uw eigen ontwerp al heeft gebroken.