Skieden útgong: VPN-pool op usb0, gateway-ferkear op eth0

Klanten ferbine en autentifearje, en dan giet har ferkear fia de ferkearde boppelink fuort, om't de iennige standertrûte op 'e masine fan 'e gateway sels is. It ferfangen fan dy standertrûte soe de eigen updates en beheardtagong fan 'e masine brekke, dus moat de seleksje smeller wêze as «alle ferkear». De wurkbere foarm is in beliedsregel basearre op it ynderlike boarneadres fan 'e klantpool, dy't nei in twadde routingstabel wiist dy't de alternative WAN hat. Fan dêrôf giet de checklist oer folsleinens en flatergedrach, net oer de regel sels.

Befêstigje dat it boarneadres oant de routingbeslissing oerbliuwt

In beliedsregel dy't mei in boarneberik oerienkomt, aktivearret allinnich as it pakket dy boarne op it momint fan it sykjen noch draacht. Trochstjoerd klantferkear docht dat, salang't neat boppe streamop it foar de routing wer skreaun hat. Ferkear dat de gateway sels generearret docht dat net, en dêrom kin de eigen standertrûte fan 'e gateway bliuwe wêr't er is.

Hjir wurde lokale tests misliedend. In curl-oprop op 'e gateway is in lokaal generearre stream mei it adres fan 'e gateway, dus nimt er de haadtabel en bewiist er neat oer it klantpaad. Test fan in ferbûne klant, of generearje ferkear mei in boarne dy't echt by de pool heart.

Begjin mei it opskriuwen fan 'e echte wearden: it poolfoarheaksel, de tunnelinterface dy't it draacht, it adres en de folgjende hop fan 'e twadde WAN, en it tabelnûmer dat jo brûke wolle. Romje de âlde regels fan elke eardere poging op foardat jo nije tafoegje, want dûbele regels op ferskate prioriteiten jouwe flaters dy't tafallich lykje.

Bou in selektearre tabel dy't folslein is

In tabel is gjin standertrûte mei in freon. Hy hat genôch rûtes nedich sadat elke syktocht binnenyn oplost, ynklusyf de ferbûne rûte foar it WAN-subnet sadat de folgjende hop berikber is. Foar in pool fan 10.77.0.0/24 op tun1, in WAN-adres fan 203.0.113.20/24 mei folgjende hop 203.0.113.1, en tabel 600:

ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600

De regel stiet op in prioriteit ûnder elke besteande allesfanger-regel, dus passende klanten reitsje earst tabel 600 en al it oare falt troch nei de haadtabel. De ip-rule-referinsje beskriuwt it oardere sykmodel en de selector-syntaksis folslein.

Tink dan oan wat de tabel net befettet. In bestimming dy't allinnich in rûte yn haad hat, lykas in behearsubnet dat fia eth0 berikber is, wurdt net yn tabel 600 fûn en falt net werom nei haad as dêr ienris in standertrûte is. As dy paden wichtich binne, foegje se dan eksplisyt ta oan 'e selektearre tabel, wat meastentiids it goede antwurd is foar in VPN-útgongstabel.

Hâld it eigen ferkear fan 'e listener bûten it belied

De OpenVPN-listener hat syn eigen bûtenferbining, droegen oer hokker boppelink de klant him ek berikt hat. Dat ferkear moat it werompaad hâlde wêrmei't it oankaam, en in brede regel dy't it iepenbiere adres fan 'e tsjinner of de hiele tunnelinterface omfettet, kin it yn 'e alternative tabel lûke. Behein de regel ta de ynderlike pool en neat oars.

Filtering fan it werompaad fertsjinnet om deselde reden in eachopslach. As antwurden oan klanten fia usb0 fuortgeane wylst it fersyk oer in oare skeakel oankaam, kin in strange rp_filter-ynstelling pakketten fuortsmite dy't it routingbelied jildich achtet. Kontrolearje de effektive sysctl-wearden op beide interfaces foardat jo konkludearje dat de regel mislearre is.

Oarder is ek wichtich foar al it oare op 'e masine. Docker-brêgen, in twadde VPN en alle besteande regels út in provider-image foegje prioriteiten ta, dus lês de folsleine regellist ynstee fan oan te nimmen dat prioriteit 100 allinnich is.

Lit trochstjoeren en oersetting mei de rûte oerienkomme

Routing kiest in boppelink; it jout gjin tastimming om troch te stjoeren. De kernel moat IPv4-trochstjoeren oan hawwe, en de firewall moat de rjochting fan klant nei WAN en it weromferkear akseptearje. In korrekte tabel mei in FORWARD-ketting dy't de stream fuortsmyt, jout itselde symptoom as in ûntbrekkende rûte, dêrom wurde beide yn deselde trochgong kontrolearre.

As de twadde WAN in privee pool net werom nei jo rûtet, oerset dan de boarne op dy útgong. Foar in interface mei in dynamysk adres is in smelle masquerade-regel beheind ta de pool en it interface de gewoane kar:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE

It berik is hjir wichtiger as it doel. In masquerade-regel dy't mei elk útgeand interface oerienkomt, sil ek ferkear oerskriuwe dat korrekt fia eth0 fuortgiet, en dat ferberget routingflaters ynstee fan se te reparearjen. Oersetting rint nei de routingbeslissing, dus kin nea in pakket reparearje dat nei de ferkearde boppelink stjoerd is.

Tuneloerhead freget ek omtinken sadree't paden ferskille. As klanten in grutte TCP-MSS ôfprate en de alternative WAN hat in legere MTU of in tunnel derbinnen, dan stûkje grutte segminten wylst lytse wurkje. MSS klemme op it trochstjoerpaad makket dêrfoar foarsisber gedrach ynstee fan in inkeld fêstrinnen.

Beslis wat der bart as usb0 ferdwynt

In lege tabel is gjin tastân dy't by flater slút. As de passende rûte ferdwynt, giet de syktocht troch nei de folgjende regel, berikt de haadtabel en nimt de eth0-standert. Ferkear dat fia de twadde WAN fuortgean moatten hie, giet stilwei fia de earste, wat foar in beliedsrûtearre útrol meastentiids it útkomst is dy't jo it minst wolle.

Wêr't dy weromfal net akseptabel is, foegje in eksplisite terminale rûte ta yn tabel 600, lykas in blackhole-standert, of smyt de pool yn 'e firewall fuort wylst it interface del is. Elts fan beide is in beslissing dy't jo opskriuwe kinne; stilte is dat net.

Folfêstens is it lêste punt. Wa't ek beide skeakels hat, oft dat de netwurkbehearder, in dispatcher-skript of de libbenssyklus fan 'e ferbining is, moat by elke werferbining de rûtes en de regel opnij meitsje sûnder dûbelingen ta te foegjen. Ferifiearje mei in fersyk fan in echte klant en in apart fersyk fan 'e gateway, befêstigje de waarnommen útgong by beide, lûk dan de twadde WAN út en sjoch hokker fan 'e twa útkomsten dy't jo ûntwurpen hawwe echt bart. IPv6 hat syn eigen tabel, regel en oersetting nedich; de IPv4-regel hjirboppe seit neat dêroer.