pfSense OpenVPN: bereik ’n netwerk agter ’n ander router

Jou skootrekenaar bereik die pfSense-LAN oor die VPN en slaag steeds nie daarin om ’n diens twee spronge verder in te bereik nie, en die verskil is een roetebesluit per eienaar. Drie toestelle moet saamstem voordat ’n pakkie sy heen-en-weer-reis voltooi: die kliënt, die vuurmuur en die router wat die bestemmingsnetwerk werklik besit. Mis enige een van hulle en die simptoom lyk identies.

Volg een pakkie deur daardie drie besluite voordat jy ’n reël verander, want elke eienaar het ’n ander beheer en ’n ander foutmodus.

Een pakkie, drie roetebesluite

Die kliënt besluit of die bestemming in die tonnel hoort, en dit kan net besluit op grond van wat dit weet: ’n gestuurde roete, ’n plaaslike roete of ’n verstekroete wat reeds alles dek. pfSense besluit waarheen om die pakkie volgende te stuur, wat vir ’n netwerk agter ’n ander router ’n statiese roete deur ’n bereikbare poort op die korrekte koppelvlak beteken. Die stroomafwaartse router besluit of hy ’n pad terug na die VPN-poel ken, en indien nie, word die antwoord laat val of na ’n nuttelose plek gestuur. Elke besluit is onafhanklik van die ander twee.

Die mislukking van enige enkele een lewer dieselfde gebruikersverslag. Daarom maak die ontfoutingsorde meer saak as die gereedskap.

Gee die kliënt ’n voorvoegsel, nie ’n raaiskoot nie

Op ’n pfSense SSL/TLS-bediener met ’n IPv4-tonnelnetwerk groter as ’n /30, versprei die veld IPv4-plaaslike netwerk(e) roetes na kliënte wanneer hulle verbind. Voeg die stroomafwaartse voorvoegsel daar by eerder as om op die kliënt te vertrou om een uit te dink. Lees dan die kliënt se werklike tabel nadat jy verbind het, want ’n profiel met route-nopull of ’n roetefilter kan ignoreer wat die bediener gestuur het. Die bediener kan heeltemal korrek wees terwyl die kliënt niks installeer nie.

Ander bedienerwyses en topologieë het verskillende beperkings, en beleid per kliënt of per verbinding kan verander wat ’n spesifieke kliënt ontvang. Verifieer op die kliënt wat saak maak eerder as op watter een jy toevallig eerste getoets het.

Wys pfSense na die interne router

’n Statiese roete in pfSense het ’n poort nodig wat gedefinieer en bereikbaar is, en die koppelvlak wat vir daardie poort gekies word, moet die een wees wat dit werklik bereik, soos die Netgate-gids vir statiese roetes beskryf. In ’n illustratiewe uitleg is die deurvoerskakel 192.168.77.1 op die vuurmuur en 192.168.77.2 op die interne router, met die diensnetwerk op 172.16.30.0/25 agter dit. Die roete noem dan die voorvoegsel en die volgende sprong, nie die diensadres nie. Om ’n adres uit die afgeleë netwerk as die poort te gebruik, is ’n algemene manier om ’n roete te bou wat korrek lyk en nêrens heen stuur nie.

Om ’n koppelvlak ’n naam te gee, beskryf nie die netwerke anderkant dit nie. Die statiese roete is daardie beskrywing.

Die ver kant moet die poel ken

Die stroomafwaartse router het ’n terugroete vir die poel nodig, in hierdie voorbeeld 10.55.0.0/24 via 192.168.77.1, tensy ’n verstekroete of ’n dinamiese protokol reeds een voorsien. Die diensgasheer se eie poort moet na daardie router lei, wat gewoonlik waar is wanneer die router sy verstekpoort is en onwaar wanneer die gasheer met die hand opgestel is. Beleidsroetering op die vuurmuur kan ook die tabel vir spesifieke verkeer oorheers, so kyk eers of ’n reël ’n ander poort kies voordat jy besluit die roete is verkeerd.

Geen vertaling word vir hierdie ontwerp vereis nie, en om die kliënt se bronadres sigbaar te hou, laat die stroomafwaartse netwerk sy eie beleid toepas.

Volg vir aanvaarding een vars versoek deur die tonnelingang, die vuurmuur se interne uitgang en die antwoord van die bestemming. As vertaling eerder doelbewus gebruik word, teken op watter bron die stroomafwaartse netwerk sien en hoe die antwoord verwag word om terug te kom.

Stoor die drieeienaarplan saam met die toegelate toepassing, sodat die volgende administrateur die pad kan herkonstrueer eerder as om dit weer te ontdek.