It oansetten fan in OpenVPN-klant mei folsleine tunnel op in masine dy'tst oer SSH berikst, kin it sesje binnen in sekonde ôfsnije, en de masine docht neat ferkeard. De tunnel feroaret net hoe't pakketten de tsjinner berikke; hy feroaret hoe't de antwurden fuortgean. Sadree't de standertrûte nei tun0 wiist, giet in antwurd oan dyn SSH-klant de netwurk fan de oanbieder yn, dat gjin rûte werom nei dyn adres hat. De ferbining hinget, de folgjende poging rint ôf, en de daemon bliuwt de hiele tiid op poarte 22 harkje.

Lês de rûtetabel foardatst it VPN-loch lêst. It loch sil sizze dat de tunnel omheech kaam, en it hat gelyk. De fraach is oan hokker interface elk antwurd jûn wurdt, en dat is in sykjen per pakket yn in tabel dy't de tunnel krekt oerskreaun hat.

Wêrom't it antwurd troch de ferkearde doar fuortgiet

Ynkommende pakketten komme noch altyd op 'e fysike interface oan, om't in VPN-klant net feroarje kin hoe't it ynternet it iepenbiere adres fan dyn tsjinner berikt. Antwurden binne in aparte beslissing: foar elk pakket siket de kernel it bestimming op, en nei --redirect-gateway seit de standertynfiere tunnel. De útgong fan de oanbieder sjocht in bestimming dy't er net betsjinnet en smyt it pakket fuort.

De eigen beskerming fan OpenVPN dekt krek ien bestimming. De hânlieding foar 2.6 beskriuwt --redirect-gateway as in searje: hy foeget in hostrûte foar de VPN-peer ta fia de gateway dy't foar de tunnel brûkt waard, sadat it fersifere ferkear net yn himsels werom rinne kin, en ferfangt dan de standertrûte. Dy hostrûte is allinnich foar de peer. Dyn SSH-klant is gewoan noch in ynternetadres en krijt gjin útsûndering.

Ien foarheakselflater is it wurdich betiid út te sluten. ip route add -net 0.0.0.0 gw 10.8.0.1 dev tun0 sûnder lingte past by it ienige adres 0.0.0.0, net by it ynternet; it moat 0.0.0.0/0 wêze. En as it nimmen fan 'e standert de eigen ferfier fan de tunnel brekt, foegje it einpunt as hostrûte fia de fysike interface ta, mei it echte adres fan de oanbieder.

Pynje dyn SSH-klantadres fêst foar in direkte oplossing

De fluchste reparaasje is in hostrûte foar dyn klantadres fia de gateway dy't de tsjinner foar de tunnel brûkte. Fan dyn kant, fyn it adres dat de tsjinner sjen sil, lês dan de tabel fan de tsjinner om de âlde gateway te kennen:

curl -s https://ifconfig.co
ip route

Op de tsjinner, foegje de útsûndering ta foardat de klant start. De adressen hjir binne plakhâlders; de foarm is wat telt:

sudo ip route add 80.128.240.55 via 192.168.178.1

Dit is de reparaasje dy't yn it rapportearre gefal brûkt is, en hy wurket daliks. Hy is ek bros op twa foarsisbere manieren: de rûte ferdwynt by it opnij starten, en hy wurdt ferkeard op it stuit dat dyn ISP dy in oar adres jout. Behannelje it as in needmaatregel en meitsje it bewust duorsum, fia in netwurk-ienheid of in dispatcher-hook, of akseptearje dat it tydlik is en skriuw it werstelpaad op.

Stop de klant derfan de standert te nimmen

De skjinere opsje is om de tunnel de standertrûte hielendal net ferfange te litten. route-nopull, brûkt mei --client of --pull, akseptearret de stjoerde opsjes behalve rûtes, block-outside-dns en DHCP-achtige opsjes lykas DNS-tsjinners, sadatst allinnich de foarheakels tafoegest dy'tst nedich hast. In smeller ark is in lûkfilter, dat ien ferkearde rjochtline fuortsmyt en de rest hâldt:

route-nopull
pull-filter ignore "redirect-gateway"

Brûk it iene of it oare, net beide, en wês dúdlik oer wat feroaret. Sûnder standertrûte troch de tunnel sneupt de tsjinner net mear oer it ynternet fia de oanbieder; hy berikt allinnich watst eksplisyt rûtearre hast. As de folsleine tunnel it hiele doel fan de opset wie, is dit de ferkearde knop en is de hostrûte hjirboppe de juste.

Diel it werompaad op boarne of op ferbining

As it ynkommende adres stabyl is, hâldt in boarneregel de antwurden lokaal sûnder de eigen rûtes fan de tunnel oan te taasten. Jow it adres fan de fysike interface syn eigen tabel mei it LAN-foarheaksel en de fysike standert, en kies dan dy tabel foar ferkear dat dêrwei komt:

ip rule add from 192.168.1.11 table 128
ip route add table 128 to 192.168.1.0/24 dev eth0
ip route add table 128 default via 192.168.1.1

Dit wurket om't antwurden op in ynkommende SSH-ferbining komme fan it adres dêr't de klant mei ferbûn is. In rapportearre gefal wêrby't elke ynkommende tsjinst wurkje bliuwe moast, brûkte krekt dizze foarm. As it ynkommende adres driuwt of it paad dynamysk is, markearje dan de ferbining: set in conntrack-mark op it earste pakket dat fan de fysike interface komt, kopiearje it nei antwurdpakketten yn OUTPUT, en rûteje markearre pakketten fia in tabel dy't nei de fysike gateway wiist.

iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1234
iptables -t mangle -A OUTPUT -m connmark --mark 1234 -j MARK --set-mark 4321
ip route add default via 192.168.1.1 dev eth0 table 3412
ip rule add fwmark 4321 table 3412

Hâld de ferbiningsmark, firewallmark en tabelnûmer apart by it testen. It werbrûken fan ien nûmer foar twa rollen makket in regel dy't korrekt liket en de ferkearde pakketten rekket. De standertynfiere fan 'e tabel hat ek via nedich mei de LAN-gateway op in gewoane Ethernet-ferbining; in neaken dev eth0 wurket allinnich as de interface punt-nei-punt is of de folgjende hop op in oare manier oplost wurdt. De rapportearre Jessie-host siet tafallich op in ferbining dêr't de neakene foarm wurke, wat gjin distribúsjeregel is om te kopiearjen.

Ferifiearje sûnder dysels bûtendoar te sluten

Test net troch te ûntkoppeljen. Hâld it earste sesje iepen, bring de tunnel omheech, en freegje de kernel hokker paad dyn eigen adres nimme soe:

ip route get 80.128.240.55

It antwurd heart de fysike interface en de âlde gateway te neamen, net de tunnel. Iepenje dan in twadde SSH-ferbining; dat is de echte test, om't it âlde sesje oerlibje kin op steat dy't in nije ferbining net werjaan kin. As it twadde hinget wylst it earste noch antwurdet, hat de regel nea it ferkear rekke dat telt, en de marken of it boarne-adres binne wêr'tst sjen moatst.

Hâld in bûtenbânse konsole beskikber by de hiele oefening. In tsjinner waans iennichste tagongspaad de tunnel is dy'tst krekt brutsen hast, kin net oer dy tunnel reparearre wurde, en it weromrinnen is makliker as't de tabelnûmers en foarheakels opskreaun hast dy'tst tafoege hast.

Relatearre artikelen