pfSense OpenVPN: en Netzwierk hannert engem anere Router erreechen

Däin Laptop erreecht de pfSense-LAN iwwer d'VPN a kënnt awer net un e Service zwee Hops méi wäit bannen, an den Ënnerscheed ass eng Routingentscheedung pro Besëtzer. Dräi Apparater mussen iech eeneg ginn, ier e Pak säi Wee hin an zréck fäerdeg mécht: de Client, d'Firewall an de Router, deen tatsächlech d'Zilnetzwierk besëtzt. Verléiers een dovun an d'Symptomer gesinn gläich aus.

Verfolleg e Pak duerch déi dräi Entscheedungen, ier s du eng Regel änderst, well all Besëtzer eng aner Kontroll an en anere Fehlermodus huet.

Ee Pak, dräi Routingentscheedungen

De Client entscheet, ob d'Zil an den Tunnel gehéiert, an hie kann nëmmen aus deem entscheeden, wat hie weess: eng gepushte Route, eng lokal Route oder eng Standardroute, déi schonn alles deckt. pfSense entscheet, wouhin de Pak als nächstes geet, wat fir en Netzwierk hannert engem anere Router eng statesch Route duerch eng erreechbar Gateway op der richteger Interface bedeit. De Router ënnen entscheet, ob hien e Wee zréck an de VPN-Pool kennt, a wann net, gëtt d'Äntwert verworf oder op eng nëtzlos Plaz geschéckt. All Entscheedung ass onofhängeg vun den aneren zwou.

De Fehler vun enger vun hinnen ergëtt deeselwechte Benotzerbericht. Dofir ass d'Reiefolleg beim Debuggen méi wichteg wéi d'Instrumenter.

Gëff dem Client e Präfix, keng Vermutung

Op engem pfSense SSL/TLS-Server mat engem IPv4-Tunnelnetzwierk gréisser wéi en /30 verdeelt d'Feld IPv4 Local network(s) Route un d'Clienten, wa se sech verbannen. Setz de Präfix ënnen do bäi, amplaz drop ze vertrauen, datt de Client een erëmfënnt. Liest dann d'tatsächlech Tabell vum Client no der Verbindung, well e Profil mat route-nopull oder e Routefilter ka ignoréieren, wat de Server geschéckt huet. De Server ka komplett richteg sinn, während de Client näischt installéiert.

Aner Servermodi an Topologië hunn aner Grenzen, an eng Politik pro Client oder Verbindung ka änneren, wat ee bestëmmte Client kritt. Verifizéier op deem Client, deen zielt, net op deem, deen s du zoufälleg als éischten getest hues.

Richt pfSense op den internen Router

Eng statesch Route an pfSense brauch eng definéiert an erreechbar Gateway, an d'Interface, déi fir där Gateway gewielt gëtt, muss déi sinn, déi se tatsächlech erreecht, wéi den Netgate-Leitfued fir statesch Route beschreift. An engem illustrativen Opbau ass den Transitlink 192.168.77.1 op der Firewall an 192.168.77.2 um internen Router, mam Servicenetz op 172.16.30.0/25 dobannen. D'Route nennt dann de Präfix an den nächsten Hop, net d'Serviceadress. Eng Adress aus dem wäiten Netzwierk als Gateway ze benotzen ass e geleefege Wee, eng Route ze bauen, déi richteg ausgesäit an néierens hin viruleet.

Engem Interface en Numm ginn beschreift d'Netzwierker dobannen net. D'statesch Route ass déi Beschreiwung.

Déi wäit Säit muss de Pool kennen

De Router ënnen brauch eng Zréckroute fir de Pool, an dësem Beispill 10.55.0.0/24 iwwer 192.168.77.1, ausser eng Standardroute oder en dynamesche Protokoll liwwert schonn eng. D'Gateway vum Servicehost selwer muss Richtung deem Router féieren, wat normalerweis richteg ass, wann de Router seng Standardgateway ass, a falsch, wann den Host manuell konfiguréiert gouf. Policy-Routing op der Firewall ka fir bestëmmten Traffic d'Tabell och iwwerschreiwen, also kontrolléier, ob eng Regel eng aner Gateway wielt, ier s du schléiss, datt d'Route falsch ass.

Fir dësen Design ass keng Iwwersetzung noutwendeg, an d'Quelladress vum Client sichtbar ze halen erlaabt dem Netzwierk dobannen, seng eege Politik unzewennen.

Fir d'Acceptance verfolleg eng nei Ufro duerch den Tunnelagang, den internen Ausgang vun der Firewall an d'Äntwert vum Zil. Wann amplaz bewosst Iwwersetzung benotzt gëtt, notéier, wéi eng Quell d'Netzwierk dobannen gesäit a wéi d'Äntwert erwaart gëtt zréckzekommen.

Späicher de Plang vun den dräi Besëtzer nieft der erlaabter Applikatioun, sou datt den nächsten Administrateur de Wee ka rekonstruéieren, amplaz en nees z'entdecken.