pfSense OpenVPN: in netwurk efter in oare router berikke
De klient hat in ta-stjoerd prefiks nedich, pfSense hat in berikbere folgjende hop nedich, en de fiere router hat in wei werom nei de pool nedich. Trije eigners, trije rûtes.
Jo laptop berikt it pfSense-LAN oer de VPN en slagget der dochs net yn om in tsjinst twa hops fierder te berikken, en it ferskil is ien routingbeslút per eigner. Trije apparaten moatte it iens wêze foar't in pakket syn reis hinne en wer foltôget: de klient, de firewall en de router dy't it bestimmingsnetwurk eins besit. Mis ien fan har en it symptoom liket identyk.
Folgje ien pakket troch dy trije besluten foar't jo in regel feroarje, want elke eigner hat in oare kontrôle en in oare flatermodus.
Ien pakket, trije routingbesluten
De klient beslút oft it bestimming by de tunnel heart, en kin allinnich beslute út wat er wit: in ta-stjoerde rûte, in lokale rûte of in standertrûte dy't al alles dekt. pfSense beslút wêr't it pakket folgjende hinne moat, wat foar in netwurk efter in oare router in statyske rûte troch in berikbere gateway op it krekte ynterface betsjut. De router deller beslút oft er in wei werom nei de VPN-pool ken, en sa net, dan wurdt it antwurd weilitten of nei in nutteleaze plak stjoerd. Elk beslút is ûnôfhinklik fan de oare twa.
It mislearjen fan ien fan harren jout itselde brûkersrapport. Dêrom is de folchoarder fan debuggen wichtiger as it ark.
Jou de klient in prefiks, gjin gissing
Op in pfSense SSL/TLS-tsjinner mei in IPv4-tunnelnetwurk grutter as in /30 ferspriedt it fjild IPv4 Local network(s) rûtes nei klanten as se ferbine. Foegje it prefiks deller dêr ta ynstee fan te fertrouwen op de klient om ien te betinken. Lês dan de wiere tabel fan de klient nei it ferbinen, want in profyl mei route-nopull of in rûtefilter kin negearje wat de tsjinner stjoerd hat. De tsjinner kin folslein korrekt wêze wylst de klient neat ynstallearret.
Oare tsjinnermodi en topologyen hawwe oare grinzen, en belied per klient of ferbining kin feroarje wat in beskate klient ûntfynt. Ferifiearje op de klient dy't fan belang is, net op dy't jo tafallich earst testen.
Wize pfSense nei de ynterne router
In statyske rûte yn pfSense hat in definesarre en berikbere gateway nedich, en it ynterface dat foar dy gateway keazen wurdt moat it ien wêze dat der eins berikt, sa't de Netgate-gids foar statyske rûtes beskriuwt. Yn in yllustrative yndieling is de transitoferbining 192.168.77.1 op de firewall en 192.168.77.2 op de ynterne router, mei it tsjinstnetwurk op 172.16.30.0/25 dêrefter. De rûte neamt dan it prefiks en de folgjende hop, net it tsjinstadres. It brûken fan in adres út it fiere netwurk as gateway is in gewoane manier om in rûte te bouwen dy't korrekt liket en nearne hinne stjoert.
In ynterface in namme jaan beskriuwt de netwurken dêrefter net. De statyske rûte is dy beskriuwing.
De fiere kant moat de pool kenne
De router deller hat in weromrûte foar de pool nedich, yn dit foarbyld 10.55.0.0/24 fia 192.168.77.1, útsein as in standertrûte of in dynamysk protokol al ien leveret. De gateway fan de tsjinsthost sels moat nei dy router liede, wat normaal wier is as de router syn standertgateway is en falsk as de host mei de hân konfigurearre waard. Beliedsrouting op de firewall kin ek de tabel foar beskaat ferkear oerskriuwe, dus kontrolearje oft in regel in oare gateway kiest foar't jo konkludearje dat de rûte ferkeard is.
Foar dit ûntwerp is gjin oersetting nedich, en it sichtber hâlden fan it boarneadres fan de klient lit it netwurk deller syn eigen belied tapasse.
Foar akseptaasje folgje jo ien nij fersyk troch de tunnelyngong, de ynterne útgong fan de firewall en it antwurd fan 'e bestimming. As ynstee bewust oersetting brûkt wurdt, skriuw dan op hokker boarne it netwurk deller sjocht en hoe't it antwurd ferwachte wurdt werom te kommen.
Bewarje it plan fan de trije eigners njonken de tastiene applikaasje, sadat de folgjende behearder it paad rekonstruearje kin ynstee fan it op 'e nij te ûntdekken.