Firwat ass de Subnet hannert engem OpenVPN-Client net erreechbar?

Pings op d'Tunneladress vum Server geléngen, d'Routertabell vum Client selwer gesäit richteg aus, an d'LAN hannert deem Client ass nach ëmmer net erreechbar. D'Routingtabell vum Client gesäit korrekt aus, de Server huet eng Route Richtung Tunnel, an d'Pakete verschwannen nach ëmmer. Et ass de klassesche Symptom vun engem Layer-3-Tunnel, dee net weess, datt ee vu senge Clienten och en Gateway ass.

En tun-Interface huet keen nächsten Hop pro Client. De Kernel gesäit een eenzegt Interface mat ville Peers, dofir muss d'Decisioun, wéi ee Client e Paket fir eng wäit ewech LAN kréie soll, bannent dem OpenVPN-Prozess geholl ginn. Déi Decisioun gëtt mat iroute konfiguréiert, an ouni si huet d'Paket néierens fir hinzegoen.

De Server routet pro Client, net pro Interface

Wann de Server e Paket op d'Tunneladress vun engem Client schécke muss, ass d'Äntwert eendeiteg: d'Adress gehéiert zu der Sessioun vun deem Client. Wann d'Destinatioun en ganze Subnet hannert deem Client ass, gehéiert d'Adress zu keenem, deen de Server kennt, an d'Kernelroute zum Tunnel seet just "duerch dëst Interface", ouni ze soen, wéi ee Peer.

OpenVPN léist dat mat enger interner Routingtabell, déi en Destinatiounspräfix engem bestëmmte Client zouuerdnet. Déi Tabell gëtt aus iroute-Anträg opgebaut, dofir duerf eng gewéinlech Route um Serverhost net. D'Kernelroute bréngt d'Paket op den Tunnelinterface; déi intern Zouuerdnung entscheet, wéi eng Sessioun et kritt. Dofir erschéngt d'Reparatur och ni an der Routenausgab vum Kernel.

Feelt d'Zouuerdnung, kënnt d'Paket um Server un, passt op d'Tunnelroute a gëtt verworf, well kee Client d'Destinatioun beusproocht. Näischt logt e kloeren Feeler, dofir gesäit de Feeler aus wéi e stille schwaarzt Lach an net wéi eng Routingsschleif.

Den iroute-Antrag schreiwen, deen de Client nennt

iroute lieft an enger clientspezifescher Konfiguratiounsdatei, net an der Haaptkonfiguratioun vum Server. Richt de Server op en Verzeechnes mat der Optioun client-config-dir, erstellt dann eng Datei, där hiren Numm den gemeinsamen Numm vum Zertifikat vum Client ass, a leet de Präfix dodran.

Fir eng Filial, där hir LAN 10.20.0.0/24 ass an där hiren gemeinsamen Zertifikatsnumm branch-router ass, enthält d'Datei op deem Wee eng Linn wéi iroute 10.20.0.0 255.255.255.0. D'Haaptkonfiguratioun brauch just d'Verzeechnesoptioun; de Präfix lieft beim Client.

De gemeinsamen Numm ass de fragilen Deel. En Zertifikat, deen mat engem aneren subject ausgestallt gouf, oder eng Installatioun, déi Benotzer iwwer de Benotzernumm authentifizéiert, während d'Datei nom Zertifikat genannt ass, produzéiert eng Datei, déi ni gelies gëtt. Préift den Numm, deen de Server tatsächlech fir d'Sessioun mellt, a betruecht d'Optioun, déi en net passende Client feele léisst, amplaz datt en sech stillech ouni seng Ruten verbënnt. D'Datei ëmbenennen, soudatt se zum Zertifikat passt, ass eng fënnefminutteg Korrektur, déi en immens laangen Owend verhënnert.

Ee Client kann méi Präfixer besëtzen. Füügt eng iroute-Linn pro Netzwierk bäi, a haalt d'Lëscht nieft de Rescht vun den Astellunge vun deem Client, soudatt d'Zouuerdnung iwwerpréifbar bleift.

De Retourwee a béide Richtungen bauen

D'Pakete bis an d'wäit ewech LAN ze bréngen ass d'Halschent vun der Aarbecht. De Client muss och den Traffic vun där LAN an den Tunnel schécken, wat normalerweis duerch Drécke vun enger Route zum Client gemaach gëtt: eng Linn wéi push "route 10.8.0.0 255.255.255.0" seet all Client, wéi en d'Netz op der Serversäit erreecht. Fir d'Filial weist déi gläichwäerteg Route op den Tunnel fir alles, wat se op der Serversäit erreeche soll.

D'Retourrichtung brauch en Eegentemer op der wäiter Säit. Op där Säit muss een de Wee zréck kennen: eng statesch Route um LAN-Router, déi de VPN-Pool op de Server weist, oder Adressiwwersetzung um Server, ier den Traffic an d'LAN kënnt. Déi statesch Route hält d'Originaladressen a Loggen an Zougangsreegele sichtbar, brauch awer d'Zesummenaarbecht vum LAN-Eegentemer; d'Iwwersetzung ass selbststänneg, awer verstoppt, wien sech tatsächlech verbonnen huet.

D'Weiderleitung muss um Serverhost aktivéiert sinn. Ouni si hëlt de Kernel d'Paket aus dem Tunnel un a refuséiert et op den LAN-Interface weiderzeginn, wat aus der Siicht vum Client identesch mat enger feelender iroute ausgesäit.

D'Erreechbarkeet mat de richtege Sonden préifen

Test an Schichten amplaz de wäiten Enn ze pingelen an ze roden. Vum Server aus préift, datt déi intern Zouuerdnung fir de Präfix existéiert an datt d'Kernelroute op den Tunnel weist. Vum Client aus bestätegt, datt déi gedréckt Route installéiert ass an datt säi Standardwee fir d'LAN-Adress den Tunnel ass.

Kuckt dann d'Paketen un. Eng Opnam um Tunnelinterface weist, ob de Server Richtung Client iwwerdréit, an eng Opnam um LAN-Interface weist, ob en weiderleitet. Weist déi éischt Paketen an déi zweet näischt, ass d'Weiderleitung oder e Filter de Problem; weist keng vun deenen zwee eppes, ass d'Sich viru méi fréi gescheitert.

Zwee Serveren, déi duerch en Tunnel verbonne sinn, widderhuelen déiselwecht Regel op béide Säiten: jiddwereen brauch eng iroute fir de Pool vum aneren, a jiddwereen brauch d'Route an d'Weiderleitung, déi de Wee symmetresch maachen. Routing a Politik sinn hei getrennte Saachen. Routing entscheet, wou e Paket ka goen, während eng FORWARD-Regel entscheet, ob et däerf, also kann e Client mat zwou iroute-Linnen déi zwou Präfixer erreechen, ausser e Filter seet anescht.