Wêrom is it subnet efter in OpenVPN-klant net berikber?

Pings nei it tunneladres fan 'e tsjinner slagje, de eigen rûtekaart fan 'e klant liket goed, en it LAN efter dy klant is noch altyd net berikber. De rûtekaart fan 'e klant liket korrekt, de tsjinner hat in rûte nei de tunnel, en pakketten ferdwine noch altyd. It is it klassike symptoom fan in layer-3-tunnel dy't net wit dat ien fan syn klanten ek in gateway is.

In tun-ynterface hat gjin folgjende hop per klant. De kernel sjocht ien ynterface mei in protte peers, dus de beslissing hokker klant in pakket foar in fiere LAN krije moat, moat binnen it OpenVPN-proses nommen wurde. Dy beslissing wurdt konfigurearre mei iroute, en sûnder dy hat it pakket nearne om hinne te gean.

De tsjinner rûtet per klant, net per ynterface

As de tsjinner in pakket nei it tunneladres fan in klant stjoere moat, is it antwurd dúdlik: it adres heart by de sesje fan dy klant. As it bestimming in hiel subnet efter dy klant is, heart it adres by nimmen dy't de tsjinner ken, en de kernelrûte nei de tunnel seit allinne "út dit ynterface", sûnder te sizzen hokker peer.

OpenVPN lost dat op mei in ynterne rûtekaart dy't in bestimmingsprefiks oan in spesifike klant keppelt. Dy tabel wurdt boud út iroute-ynskriuwingen, dêrom is in gewoane rûte op 'e tsjinnerhost net genôch. De kernelrûte bringt it pakket nei it tunnel-ynterface; de ynterne keppeling beslúdt hokker sesje it kriget. Dêrom komt de reparaasje ek nea yn 'e rûte-útfier fan 'e kernel.

As de keppeling mist, komt it pakket by de tsjinner oan, past by de tunnelrûte en wurdt it weilitten om't gjin klant de bestimming opeasket. Neat logt in skjinne flater, dêrom liket de brek as in stil swart gat ynstee fan in rûtelus.

De iroute-ynskriuwing skriuwe dy't de klant neamt

iroute wennet yn in klantspecifyk konfiguraasjebestân, net yn 'e haadkonfiguraasje fan 'e tsjinner. Wiis de tsjinner nei in map mei de client-config-dir-opsje, meitsje dan in bestân wêrfan de namme it mienskiplike namme fan it sertifikaat fan 'e klant is, en set it prefiks deryn.

Foar in filiaal wêrfan't de LAN 10.20.0.0/24 is en wêrfan't it mienskiplike sertifikaatnamme branch-router is, befettet it bestân op dat paad in rigel lykas iroute 10.20.0.0 255.255.255.0. De haadkonfiguraasje hat allinne de mapopsje nedich; it prefiks wennet by de klant.

It mienskiplike namme is it brekbere diel. In sertifikaat útjûn mei in oar subject, of in ynset dy't brûkers op brûkersnamme autentisearret wylst it bestân nei it sertifikaat neamd is, leveret in bestân dat nea lêzen wurdt. Kontrolearje de namme dy't de tsjinner echt foar de sesje rapportearret, en oerwei de opsje dy't in net-passende klant misse lit ynstee fan stil sûnder syn rûtes te ferbinen. It bestân omneame sadat it by it sertifikaat past is in fiifminuten-reparaasje dy't in heul lange jûn foarkomt.

Ien klant kin ferskate prefiksen besitte. Foegje ien iroute-rigel per netwurk ta en hâld de list njonken de oare ynstellings fan dy klant sadat de keppeling neigongber bliuwt.

De weromrûte yn beide rjochtingen bouwe

Pakketten nei de fiere LAN krije is de helte fan it wurk. De klant moat ek it ferkear fan dat LAN de tunnel yn stjoere, wat normaal dien wurdt troch in rûte nei de klant te triuwen: in rigel lykas push "route 10.8.0.0 255.255.255.0" fertelt elke klant hoe't er it netwurk oan 'e tsjinnerkant berikt. Foar de filiaal wiist de lykweardige rûte nei de tunnel foar alles wat it oan 'e tsjinnerkant berikke moat.

De weromrjochting hat in eigner oan 'e fiere kant nedich. Oan dy kant moat immen de wei werom kenne: in statyske rûte op 'e LAN-rûter dy't de VPN-pool nei de tsjinner wiist, of adresfertaaling op 'e tsjinner foar't it ferkear it LAN ynkomt. De statyske rûte hâldt de oarspronklike adressen sichtber yn logs en tagongsregels, mar freget de gearwurking fan 'e LAN-eigner; fertaaling is selsstannich mar ferberget wa't him echt ferbûn hat.

Trochstjoering moat oan wêze op 'e tsjinnerhost. Sûnder dat nimt de kernel it pakket fan 'e tunnel oan en wegeret it nei it LAN-ynterface troch te jaan, wat fan 'e klant syn eachpunt krekt as in ûntbrekkende iroute liket.

Berikberens kontrolearje mei de juste sonden

Test yn lagen ynstee fan it fiere ein te pingjen en te rieden. Fan 'e tsjinner, kontrolearje dat de ynterne keppeling foar it prefiks bestiet en dat de kernelrûte nei de tunnel wiist. Fan 'e klant, befêstigje dat de triuwde rûte ynstallearre is en dat syn standertpaad foar it LAN-adres de tunnel is.

Sjoch dan nei de pakketten. In opname op it tunnel-ynterface lit sjen oft de tsjinner nei de klant stjoert, en in opname op it LAN-ynterface lit sjen oft er trochstjoert. As de earste pakketten lit sjen en de twadde neat, is trochstjoering of in filter it probleem; as gjinien wat lit sjen, is de syktocht earder mislearre.

Twa tsjinners ferbûn troch in tunnel werhelje deselde regel oan beide kanten: elk hat in iroute nedich foar de pool fan 'e oare, en elk hat de rûte en trochstjoering nedich dy't it paad symmetrysk meitsje. Rûtering en belied binne hjir aparte saken. Rûtering beslút wêr't in pakket hinne kin, wylst in FORWARD-regel beslút oft it mei, dus in klant mei twa iroute-rigels kin beide prefiksen berikke, útsein as in filter oars seit.