It stapeljen fan in twadde OpenVPN-klant op ien Linux-host mislearret op ien fan twa plakken. Of de binnenklant berikt syn eigen server net, om't de bûtentunnel dat transport oernommen hat, of de twadde klant skriuwt de rûtetabel oer en de earste tunnel wurket net mear. Beide problemen sitte yn it rûten, net yn de fersifering, en beide wurde oplost foardat de nije tunnel applikaasjeferkear draacht. De adressen hjir binne yllustratyf: tun0 is de bûtentunnel, 203.0.113.9 is de binnenserver, en TCP 9999 is de stream dy't it binnenpaad brûke moat.

Twa mislearringsmodi, ien rûtetabel

In binnenklant iepenet in UDP-socket nei syn server, en dy socket folget de aktuele rûtetabel lykas alle oare. As de bûtentunnel al de standertrûte hat, gean de handshake-pakketten de bûtentunnel yn. Dat wurket allinnich as de bûteneserver de binnenserver berikke kin en de oare kant akkoart giet om de stream te dragen; oars stoppet de handshake en besiket de klant it opnij.

De twadde mislearring komt fan de push fan de server. De gewoane push is redirect-gateway def1, dy't 0.0.0.0/1 en 128.0.0.0/1 ynstallearret yn stee fan de standertrûte te ferfangen. Twa klanten dy't elk har eigen /1-paar ynstallearje botsingje dêrom, en it nijste pear wint foar hast elke bestimming. Sjoch yn de tabel nei dy twa prefiksen as in tunnel delslein is neidat de twadde ferbûn is, om't de standertrûte sels miskien nea feroare is.

Markearje de stream en jou him in tabel

Stjoer it selektearre ferkear troch it te markearjen yn de mangle-tabel en de mark te matsen yn in beliedsregel. De regel wiist nei in eigen tabel wêrfan de standertrûte it binnenapparaat is, sadat allinnich markearre pakketten it binnenpaad nimme.

iptables -t mangle -A PREROUTING -p tcp -m multiport --dport 9999 -j MARK --set-mark 0x9999
ip rule add fwmark 0x9999 table 200 pref 1000
ip route add default dev tun1 table 200

De measte flaters yn dizze regelset komme fan twa misseinen. De markwearde dy't de firewall ynstelt en de wearde dy't de regel matset moatte identysk wêze, om't in ferskil gjin flater en gjin effekt jout. En PREROUTING sjocht allinnich pakketten dy't fan bûten komme, dus in ferbining dy't op dizze host begûn is hat in OUTPUT-regel mei deselde match nedich foardat er hielendal markearre wurdt.

Nim rûte-eigendom by de twadde klant wei

Twa opsjes hâlde de twadde klant tsjin om de tabel te bewurkjen, en se wurkje op ferskillende plakken. route-nopull negearret de pushte rûte-opsjes, sadat der neat ynstallearre wurdt. route-noexec akseptearret de pushte opsjes yn de omjouwing fan de klant, mar lit de tabelwiziging oan in hook oer, en dat is wat jo wolle as jo sjen moatte wat de server oanbea.

De hook rint mei de pushte wearden yn syn omjouwing, en hy moat allinnich de ynfieringen tafoegje dy't jo goedkard hawwe. Meitsje him idempotint: leegje de tabel dy't er beheart foardat er wer opbouwt, en nim net oan dat de foarige run in skjinne steat efterlitten hat. In werferbining ropt de hook wer oan, en in hook dy't tafoeget sûnder te leegjen sammelt dûbele rûtes op.

Kies ien eigner en skriuw it op. In profyl dat beide opsjes ynstelt, of in hook dy't stridelet mei in hânmjittich skript, produsearret in tabel dy't nimmen letter ferklearje kin.

Fêstigje beide serveradressen

De binnenserver hat in hostrûte fia it bûtenapparaat nedich foardat de binnenklant ferbynt. Dy ynfiering hâldt it binnentransport binnen de bûtentunnel yn stee fan it de standertrûte folgje te litten.

ip route add 203.0.113.9/32 dev tun0
ip route get 203.0.113.9

Foegje ek in byhearrende hostrûte foar de bûteneserver ta yn de haadtabel, oars kin in werferbining it transport fan de bûtenklant sels yn syn eigen tunnel rûte. De folchoarder is net opsjoneel: foegje dizze ynfieringen ta neidat de relevante interface bestiet, dat betsjut in hook of in skript dy't nei it ferbinen rint. In rûte nei in apparaat dat del is wurdt fuorthelle of negearre, dus in ynfiering dy't by it opstarten skreaun is oerlibbet de folchoarder dy't jo oannommen hawwe net.

Kontrolearje de lookup yn stee fan de hiele tabel te lêzen. De útfier fan de rûte-lookup neamt it apparaat en it boarneadres dat de kernel brûke sil, en dat is krekt wat de klant krijt as er syn socket iepenet.

Test de keatling en meitsje flaters sichtber

Fange ferkear op 'e bûteninterface wylst de binnenklant ferbynt. De binnenhandshake moat as fersifere payload binnen de bûtentunnel ferskine; as er as gewoane UDP nei 203.0.113.9 ferskynt, ûntbrekt de hostrûte en is de keatling nea boud.

In keatling dy't stil weromfalt nei de fysike uplink is de minste útkomst, om't de interface-steat neat oankundiget en it binnenferkear fan it ferkearde boarneadres fuortgiet. As de twadde klant direkt werferbine kin as de bûtentunnel delgiet, skeakelje dat paad dan út of bine it oan de bûteninterface sadat de mislearring sichtber is.

Einigje mei twa streams en ien regel-dump: in markearre ferbining en in net-markearre moatte ferskillende paden nimme, en ip rule show moat de prioriteit listje dy't jo bedoelden. As beide streams itselde paad nimme, wurdt de mark net tapast wêr't jo tinke.

Relatearre artikelen