pfSense som VPN-server och -klient: två vägar, en router

En enhet kan titta i två riktningar samtidigt: roaming-användare ansluter in, och samma box ansluter ut till en utgångsleverantör så att vald trafik lämnar via ett annat nätverk. Att aktivera båda tjänsterna tar minuter; att få dem att leva sida vid sida kräver en design, eftersom den andra rollen skriver om routingtabellen som den första bygger på. Tre villkor avgör om arrangemanget fungerar, nämligen om den inkommande tjänsten behåller sin egen returväg, om den utgående tunneln fortfarande når sin peer, och om trafiken du ville vidarebefordra väljs ut för utgången. Tar du en fel får du två tunnlar som båda rapporterar ansluten medan ingenting användbart går mellan dem. Kontrollerna nedan fastställer varje villkor i den ordning felen vanligtvis visar sig.

Namnge de två rollerna innan du rör en inställning

Skriv ner fyra fakta för varje instans: dess fjärrpeer, autentiseringsmaterialet, adresspoolen den delar ut och näten bakom den. De två instanserna är separata objekt på enheten och bör förbli separata i dina anteckningar också. Nästan varje förvirrande symptom senare kommer av att blanda deras värden, och två instanser som delar en uppsättning anteckningar är hur fel pool hamnar i fel fält.

Den inkommande tjänsten behöver ett tunnelnät som inte överlappar den utgående tunnelns adresser eller något privat nät som enheten routar. Överlapp är det enda felet som ger symptom i båda rollerna samtidigt, och det är mycket billigare att fånga på papper. Jämför båda poolerna och varje routat privat nät på ett ställe innan du konfigurerar någon av tjänsterna.

Delad hårdvara betyder inte delade inloggningsuppgifter, och ett klientcertifikat från fjärråtkomstpoolen bör inte kunna användas mot utgångsleverantören. Separat material gör också återkallelse till ett lokalt beslut i stället för en händelse för hela flottan.

Håll serverns svar på WAN-vägen

Svaren som enheten själv genererar är det första offret för en slarvig standardrutt. När en roaming-användares inkapslade paket anländer är svaret lokalt uppstått trafik, och det måste lämna via det gränssnitt användaren kom in genom. Om utgångsklienten har installerat en standardrutt som fångar det, går svaret in i fel tunnel och sessionen stannar medan tjänsten fortfarande ser frisk ut.

Det finns ingen enda kryssruta som avgör detta, eftersom beslutet handlar om vilken trafik utgångsklienten får fånga. Antingen drar du inga rutter och styr bara det du väljer, eller så drar du rutter och lägger till undantagen som håller enhetens egna tjänster igång. Skriv ner valet bredvid instansen, annars kommer nästa person att anta det andra.

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

Läs routingtabellen efter längsta matchning och inte efter ordningen du konfigurerade något i. Frågan är vilken post som vinner för utgångspeerens adress och vilken post som vinner för den inkommande tjänstens svar, och de två svaren kan skilja sig.

Låt inte utgångstunneln äta sin egen ändpunkt

Utgångsklienten måste nå sin peers publika adress för att ens upprätta tunneln. Om den adressen själv routas in i tunneln jagar klienten sin egen svans: transporten kommer aldrig upp, eller så kommer den upp och faller i samma ögonblick som rutten installeras. Loggen ser ut som en autentiseringstimeout och inte som ett routningsfel, och därför förtjänar rutten den första kontrollen.

Kontrollera rutten före inloggningsuppgifterna och igen efter att tunneln är uppe, eftersom en post kan vara korrekt vid start och fel en minut senare. Peerns adress måste peka på den vanliga WAN-vägen, aldrig på tunnelenheten. När transporten är stabil flyttas den intressanta frågan till vidarebefordrad trafik, vilket är nästa beslut.

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

Välj vilka användare som får utgången

Källpolicy hör till ingången där trafiken kommer in i enheten, så välj fjärråtkomstpoolen, eller snävare identiteter inuti den. Bevara de privata destinationerna och hanteringsundantagen som aldrig får skickas till utgången, och placera dessa regler före den breda. Utgångsvägen behöver då sin egen översättning eller ett routat returarrangemang, vilket för de flesta designer betyder utgående NAT på utgångsgränssnittet som täcker poolen. Översättning väljer inte en utgång; den skriver bara om det som redan lämnat, så en NAT-regel på ett oberört WAN ändrar ingenting i urvalet.

Bekräfta att fjärränden tillåter vidarebefordrad trafik från denna design, eftersom en del leverantörer gör det och andra inte. Skillnaden visar sig som en tunnel som ansluter och inte bär något, vilket är lätt att läsa som ett lokalt fel. Testa de tre flödena separat, eftersom de misslyckas oberoende, och två av tre är en halvbyggd design.

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

Det första kommandot är roaming-användarens yttre anslutning, och det fungerar när klienten rapporterar att initieringssekvensen är klar. Det andra, kört från den anslutna laptopen, bör rapportera utgångsleverantörens adress i stället för din WAN-adress. Det tredje körs på enheten bunden till en pooladress, och det testar källpolicyn för vidarebefordrad trafik utan att involvera en fjärranvändare alls. Om det svarar från WAN i stället passade policyn inte, och ingen mängd NAT-redigering rättar ett urvalsproblem.

Bestäm vad som händer när utgången misslyckas

Skriv ner felbeteendet innan det händer: när utgångstunneln faller, faller användarna då tillbaka till det vanliga WAN eller blockeras de tills utgången kommer tillbaka? Båda svaren är försvarbara, och enheten väljer inte åt dig. En borttagen rutt eller en policy som pekar på en död gateway ger inte automatiskt ett helt blockerat resultat. Vill du ha blockering måste policyn säga det uttryckligen, och den måste testas genom att ta bort utgången i stället för att resonera om den. Vill du ha återfall, publicera det för användarna, för trafik som tyst tar den vanliga vägen är precis den trafik någon trodde var täckt.

Inaktivera klientinstansen, se vad en ansluten användare fortfarande når, och starta den sedan igen. En begäran som tar timeout är det helt blockerade resultatet du bad om; en som svarar med WAN-adressen är återfallet du inte dokumenterade. Upprepa kontrollen för IPv6 och för DNS, eftersom en policy skriven för IPv4 inte säger något om AAAA-trafik och en resolver som någon av tunnlarna skjuter igenom svarar från där frågan faktiskt lämnar.

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

Netgates recept för routad OpenVPN visar hur källpolicy, gränssnittstilldelning och utgående översättning passar ihop, och dess omfattning mellan platser är den del som inte ska kopieras i sin helhet. Det den inte kommer att berätta är vilket av de tre villkoren ovan som din egen design redan har brutit.