OpenVPN redirect-gateway: wat elke flag docht mei de rûtes

Ferbyn jo mei redirect-gateway yn it profyl, en de standertrûte fan jo masine kin ferdwine, yn twaen spjalte of krekt bliuwe wêr't er wie, ôfhinklik fan flaggen dy't nimmen twa kear lêst. De opsje feroaret allinnich de routeringssteat en neat oars, dat it iennichste betroubere bewiis fan wat er dien hat is de tabel dy't de klient dêrnei ynstallearre. Wat folget is de tabel nei in ferbining, de rûte dy't de tunnel sels libben hâldt, en it IPv6-ferkear dat de rjochtline nea beweart te dekken. Eltse stap is in opdracht dy't jo op 'e klient útfiere kinne wylst de tunnel oan is.

Wat elke flag docht mei de standertrûte

Sûnder hokker flag ek ferwideret de opsje de gewoane standertrûte en set de tunnel op syn plak, sadat de âlde poarte út 'e tabel ferdwynt wylst de ferbining oan is. Foegje def1 ta en dy standert bliuwt yn 'e list, mei twa nauwere rûtes dy't it wurk dogge. Foegje bypass-dhcp ta en de DHCP-rûte oerlibbet ek, wat fan belang is op in netwurk dêr't de klient noch altyd de pleatslike DHCP-tsjinner berikke moat. De flaglist op 'e hânliedingside fan OpenVPN 2.6 is koart genôch om ien kear te lêzen, en elk item feroaret hokker rûtes úteinlik yn 'e tabel komme.

In treaune opsje draacht him itselde as er oankomt, dat it klientprofyl kin hielendal neat befetsje wylst de tabel folslein omrûte liket. Dat is normaal: de tsjinner stjoerde de flaggen, de klient tapaste se, en it pleatslike bestân neamde de rjochtline nea. As in push liket neat te dwaan, kontrolearje it klientkantfilter dat oanlutsen opsjes akseptearret of ôfwiist, want in ôfwiisde opsje jout oan gjinien fan 'e beide kanten in flater.

def1 wint troch spesifisiteit sûnder jo standert oan te reitsjen

Twa heal-standertrûtes dekke tegearre de IPv4-romte, 0.0.0.0/1 en 128.0.0.0/1. Elk is spesifiker as 0.0.0.0/0, dat in syktocht foarkar jout oan harren wylst de echte standert yn 'e tabel bliuwt foar alles wat de minst spesifike oerienkomst freget.

Lês de tabel ynstee fan it profyl, want allinnich de tabel lit sjen yn hokker fan dy gefallen jo binne. Twa regels binne genôch om se te ûnderskieden:

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

Tink oan de ynterface en de metryk op elke regel, net allinnich oan de bestimming. In standert dy't nei de tunnel wiist en in pear heal-standerten dy't nei de tunnel wize beskriuwe deselde bedoeling en mislearje oars as de tunnel falt, want de weromfal bestiet yn ien gefal noch. Skriuw beide fjilden yn 'e feroaringsnotysje. In oerlibjende weromfal is soms wat in fiere sesje lang genôch libben hâldt om de tunnel te reparearjen, en it is ek wat ferkear lekt as de bedoeling in folsleine tunnel wie.

Hâld it einpunt fan 'e tunnel berikber

De klient hat in rûte nedich nei it fiere ein fan 'e tunnel dy't sels net troch de tunnel giet. OpenVPN ynstallearret dy hostrûte foardat it eat oars feroaret, en in hânmjittige rûtebewurking of in twadde VPN-klient kin dy weinimme. It symptoom dêrnei is in ferbining dy't seit ferbûn te wêzen en dan neat trochlit.

Freegje de kernel hokker ynterface hy brûke soe foar it einpuntadres wylst de tunnel oan is. It antwurd moat de fysike ynterface en syn poarte neame, nea tun0:

ip route get 198.51.100.20

As dy syktocht it tunnelapparaat weromjout, draacht de tunnel syn eigen ferfier en sil er yninoar stoarte sadree't in pakket nei bûten moat. Pleatslike foarheaksels, in twadde adapter en beliedsrouting binne hjir noch fan belang, dêrom kin in omrûte dy't op in skjinne laptop wurket mislearje op in host mei in behearinterface en twa standerten. It profyl krijt meastentiids de skuld foar wat it adresplan dien hat.

IPv6-ferkear bliuwt syn eigen tabel brûken

IPv4 omrûte lit IPv6 gewurde, en de twa famyljes wurde troch ferskate flaggen feroare. Op in dûbelstapel-host mei in wurkjende v6-standert kin v4-ferkear hielendal yn 'e tunnel sitte wylst elke v6-geskikte bestimming oer de fysike skeakel nei bûten giet. In host dy't yn 'e iene tabel goed liket, lekt yn 'e oare.

Kontrolearje de v6-tabel nei it ferbinen ynstee fan oan te nimmen dat de tunnel dy dekt hat. De rjochtline draacht adresfamyljeflaggen krekt om dy reden, en in profyl dat se weilitten hat, erft wat it platfoarm by ferstek docht:

ip -6 route show default
ip -6 route get 2001:db8::10

Bewiis hokker ynterface in applikaasje brûkt

In ferbûne steat is gjin blokkade, en in rûteferoaring is gjin needstop. As direkte ferkear stopje moat as de tunnel mislearret, libbet dat belied yn 'e firewall en hat it syn eigen test nedich.

Test it paad dat in applikaasje wier nimt ynstee fan it paad dat it profyl beskriuwt. Freegje earst de rûte, byn dan om 'e beurt in oanfraach oan elke ynterface en fergelykje wat de fiere kant rapportearret:

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

As beide oanfragen itselde adres weromjouwe, brûkt de applikaasje de tunnel net, ek al seit de routingstabel dat it moat. As allinnich de oanfraach dy't oan 'e tunnel bûn is slagget, is it fysike paad foar dy bestimming filtere en docht de tunnel wat jo fregen. Skriuw de flaggen, de ynstallearre rûtes, de einpuntsyktocht en beide útgongresultaten yn it feroaringsregister, sadat de folgjende persoan feiten erft ynstee fan in skermprint.