LAN-router plus VPN-klient: twa apparaten, twa rûtetabellen

Twa apparaten stjoere it pakket troch en elk hâldt syn eigen tabel by. De LAN-router wit dat it fiere prefiks by de VPN-klient heart, en de VPN-klient wit hoe’t er dat prefiks troch syn tunnel berikke moat. Konfigurearje allinnich de earste tabel en it pakket komt oan by in masine sûnder passende rûte, dus it giet wer fuort fia de standertrûte. Dat is de hiele flater, en fan de LAN-kant liket it op in rûteslingel, om’t it hast ien is.

Tekenje de twa hops foardat jo in rûte oanreitsje

Nim in yllustrative yndieling: LAN-hosts op 192.168.50.0/24, de gewoane router op 192.168.50.1, in wijdde klient op 192.168.50.15 en in fier LAN op 10.60.0.0/24 dat allinnich te berikken is fia de tunnel dy’t dy klient hâldt. Gjin fan de beide partikuliere berikken oerlaapet it oare, en de tunnel hat syn eigen adresplan.

Beide partikuliere berikken binne fan belang, om’t se beslute hokker apparaat antwurdzje kin. De fiere kant sil it pakket fan it tunneladres fan de klient ôfkommen sjen, en syn antwurd moat in wei werom fine nei 192.168.50.0/24. As allinnich de útgongrjochting konfigurearre is, kin it fersyk wurkje wylst it antwurd ferdwynt.

Stap 1: rjochtsje de router op de klient, net op de tunnel

Foegje op de LAN-router in bestimmingsrûte ta wêrfan de folgjende hop it LAN-adres fan de klient is:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Dat record seit „leverje it oan de masine dy’t tunnelje kin“. It seit neat oer hoe’t de tunnel boud wurdt, en it ferfangt de eigen rûte fan de klient net. Op in beheard router libbet it ekwivalint op ’e side foar statyske rûtes fan it apparaat; op in Linux-router heart it by de ynterfacekonfiguraasje dy’t it LAN besit, net by in shell dy’t jo slute.

Kontrolearje it antwurd fan it twadde kommando. As it de klient as gateway en it LAN-ynterface as device rapportearret, is de earste hop goed en leit it oerbleaune wurk op de oare masine.

Stap 2: jou de klient in eigen rûte oan de tunnelkant

De klient ûntfangt no in pakket foar 10.60.0.0/24 en sjocht yn syn eigen tabel. As syn tunnelkonfiguraasje in rûte foar dat prefiks ynstallearre hat, giet it pakket fersifere troch. As dat net sa is, past it pakket by de gewoane standertrûte en giet it werom nei 192.168.50.1, dat it wer nei de klient stjoert.

Sjoch earst foardat jo wat tafoegje:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

In ûntbrekkende prefiksrûte yn alle tabellen is de befinning dy’t jo sykje. Foegje dy ta fia de eigen konfiguraasje fan de tunnel, sadat de folgjende werferbining him wer ynstallearret; in manuele ip route add ferdwynt mei de sesje en lit de flater op it minst gelegen momint weromkomme. De folgjende hop is it tunnel-ynterface of it adres dat de VPN as syn pear tawiist, ôfhinklik fan de klient, en it pearadres moat út it hjoeddeistige profyl komme, net út in âlde notysje.

De slingel is, as er bart, yn ’e praktyk net einleas: de TTL sakket by elke passaazje en it pakket stjert mei in berjocht oer ferstrutsen tiid. Dêrom kin in werhelle traceroute in syklus suggerearje, wylst in klient dy’t gewoan net trochstjoert itselde pakket stil falle lit.

Stap 3: stean trochstjoering ta en kies de weromrûte

Untfangen en trochstjoere binne ferskillende rjochten. net.ipv4.ip_forward=1 op de klient staat transyt op kernnivo ta, en in firewallregel moat it noch altyd tastean tusken it LAN-ynterface en de tunnel. In regel dy’t tagong ta de eigen behearside fan de klient tastiet, sil gjin transyt nei it fiere LAN tastean, en it ûnderskie is maklik te missen as deselde host lokaal op pings antwurdet.

De fiere kant hat it spegelprobleem. Hy moat witte dat 192.168.50.0/24 fia dizze autentisearre klient te berikken is. Mei OpenVPN betsjut dat meastentiids in rûte per klient dy’t de serverkonfiguraasje útskoodt, of in klientspesifyk bestân op de server dat it LAN efter de klient ferklearret. Sûnder dat lit it fiere LAN it antwurd of falle, of it stjoert it nei syn eigen standertgateway, dat is it ynternet.

Boarne-oersetting is it alternatyf as it LAN-prefiks net oankundige wurde kin. In beheinde masquerade-regel op de klient skriuwt de boarne oer nei it tunneladres, en antwurden komme dan fansels werom. It ferberget ek hokker LAN-host it fersyk die, en it lit de fiere kant net op himsels ferbiningen nei binnen begjinne. Kies dy ôfweging bewust ynstee fan in algemiene masquerade ta te foegjen en it by-effekt letter te ûntdekken.

Stap 4: meitsje beide besluten duorjend en test dan it echte paad

Elke rûte hat in eigner, en de eigner is de konfiguraasje dy’t by it opstarten of by it werferbinen op ’e nij makke wurdt. Op de router kin dat in statyske rûte-ynfier wêze; op de klient kin dat it VPN-profyl, NetworkManager of systemd-networkd wêze. Ferifiearje troch de tunnel wer te ferbinen en de klient op ’e nij te starten, en lês dan de tabel wer, ynstee fan de bewurking te fertrouwen.

Hâld de standertrûte dy’t de bûtenferbining fan de tunnel draacht yntakt. It ferfangen derfan om de opset te „ferienfâldigjen“ brekt it fersifere paad foardat ekstra ynterne ferkear it brûke kin, en it symptoom is in tunnel dy’t nea wer opboudt nei de feroaring.

Test fan in gewoane LAN-host, net fan de klient, om’t in fersyk dat op de klient ûntstiet nea de earste hop fan de router besiket. Helje in tsjinst op dy’t allinnich op it fiere LAN bestiet en befêstigje it antwurdlichem, en besjoch dan de tellers of logboeken fan de klient om de transyt te sjen. In ynterne traceroute dy’t partikuliere hops sjen lit, bewiist trochstjoering, net fersifering: it bûtenpaad is in aparte waarnimming, en allinnich de tellers fan it tunnel-ynterface sels litte sjen wat der trochhinne gien is.