Ang buong tunnel ng OpenVPN ay pumutol sa iyong sesyon ng SSH: ayusin ang daan pabalik

Ang pag-on ng OpenVPN client na buong tunnel sa isang makinang inaabot mo sa SSH ay maaaring pumutol sa sesyon sa loob ng isang segundo, at wala namang ginagawang mali ang makina. Hindi binabago ng tunnel kung paano nakararating ang mga packet sa server; binabago nito kung paano lumalabas ang mga sagot. Sa sandaling ituro ng default na ruta ang tun0, ang sagot sa iyong SSH client ay pumapasok sa network ng provider, na walang rutang pabalik sa iyong address. Nag-hang ang koneksyon, nag-timeout ang susunod na pagtatangka, at patuloy na nakikinig ang daemon sa port 22 sa buong oras.

Basahin ang routing table bago mo basahin ang log ng VPN. Sasabihin ng log na umangat ang tunnel, at tama ito. Ang tanong ay kung aling interface ipinapasa ang bawat sagot, at iyon ay paghahanap sa bawat packet sa isang table na kabisang isinulat muli ng tunnel.

Bakit lumalabas ang sagot sa maling pinto

Ang mga papasok na packet ay dumarating pa rin sa pisikal na interface, dahil hindi mababago ng VPN client kung paano naaabot ng internet ang pampublikong address ng iyong server. Ang mga sagot ay hiwalay na desisyon: para sa bawat packet, hinahanap ng kernel ang destinasyon, at pagkatapos ng --redirect-gateway sinasabi ng default na entry na tunnel. Nakikita ng labasan ng provider ang isang destinasyong hindi nito pinaglilingkuran at itinatapon ang packet.

Ang sariling proteksyon ng OpenVPN ay sumasakop nang eksakto sa isang destinasyon. Inilalarawan ng manwal ng 2.6 ang --redirect-gateway bilang isang pagkakasunod-sunod: nagdaragdag ito ng host route para sa VPN peer sa pamamagitan ng gateway na ginamit bago ang tunnel, upang hindi makabalik sa sarili ang naka-encrypt na trapiko, at pagkatapos ay pinapalitan ang default na ruta. Ang host route na iyon ay para lamang sa peer. Ang iyong SSH client ay isa lamang internet address at walang natatanggap na pagbubukod.

Sulit nang maagang isantabi ang isang pagkakamali sa prefix. Ang ip route add -net 0.0.0.0 gw 10.8.0.1 dev tun0 na walang haba ay tumutugma sa nag-iisang address na 0.0.0.0, hindi sa internet; dapat itong 0.0.0.0/0. At kung ang pagkuha ng default ay sinira ang sariling transport ng tunnel, idagdag ang endpoint bilang host route sa pamamagitan ng pisikal na interface, gamit ang totoong address ng provider.

I-pin ang address ng iyong SSH client para sa agarang pag-aayos

Ang pinakamabilis na pag-aayos ay isang host route para sa address ng iyong client sa pamamagitan ng gateway na ginamit ng server bago pa umiral ang tunnel. Sa iyong panig, hanapin ang address na makikita ng server, pagkatapos ay basahin ang table ng server upang malaman ang lumang gateway:

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

Sa server, idagdag ang pagbubukod bago magsimula ang client. Ang mga address dito ay placeholder; ang hugis ang mahalaga:

sudo ip route add 80.128.240.55 via 192.168.178.1

Ito ang pag-aayos na ginamit sa iniulat na kaso, at gumagana ito agad. Marupok din ito sa dalawang mahuhulaang paraan: nawawala ang ruta sa reboot, at nagiging mali ito sa sandaling bigyan ka ng ISP ng ibang address. Ituring itong emergency na hakbang at gawin itong matibay nang sadya, sa pamamagitan ng network unit o dispatcher hook, o tanggapin na pansamantala ito at isulat ang daan ng pagbawi.

Pigilan ang client na kunin ang default na ruta

Ang mas malinis na opsyon ay pigilan ang tunnel na palitan ang default na ruta. Ang route-nopull, kapag ginamit kasama ng --client o --pull, ay tumatanggap ng mga itinulak na opsyon maliban sa mga ruta, block-outside-dns at mga opsyon na gaya ng DHCP tulad ng mga DNS server, kaya ang idinadagdag mo lang ay ang mga prefix na kailangan mo. Ang mas makitid na kasangkapan ay isang pull filter, na nagtatapon ng isang problemadong direktiba at pinapanatili ang iba pa:

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

Gamitin ang isa o ang isa, hindi pareho, at maging malinaw kung ano ang nagbabago. Kung walang default na ruta sa tunnel, hindi na nagba-browse ng internet ang server sa pamamagitan ng provider; naaabot lamang nito ang tahasang ni-route mo. Kung ang buong tunnel ang buong layunin ng setup, mali ang switch na ito at ang host route sa itaas ang tama.

Paghiwalayin ang daan pabalik ayon sa pinagmulan o sa koneksyon

Kapag matatag ang papasok na address, pinapanatili ng panuntunan ng pinagmulan ang mga sagot sa lokal nang hindi hinahawakan ang sariling ruta ng tunnel. Bigyan ang address ng pisikal na interface ng sarili nitong table na may prefix na LAN at pisikal na default, pagkatapos ay piliin ang table na iyon para sa trapikong nagmumula roon:

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

Gumagana ito dahil ang mga sagot sa papasok na koneksyon ng SSH ay nagmumula sa address na konektado ng client. Ang iniulat na kaso kung saan kailangang magpatuloy sa paggana ang bawat papasok na serbisyo ay gumamit nang eksakto sa hugis na ito. Kapag ang papasok na address ay lumulutang o dinamiko ang daan, markahan ang koneksyon sa halip: lagyan ng marka ng conntrack ang unang packet mula sa pisikal na interface, kopyahin ito sa mga sagot na packet sa OUTPUT, at i-route ang mga markadong packet sa isang table na tumuturo sa pisikal na gateway.

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

Ihiwalay ang marka ng koneksyon, marka ng firewall at numero ng table habang nagsubok. Ang muling paggamit ng isang numero para sa dalawang papel ay gumagawa ng panuntunang mukhang tama at tumatama sa maling packet. Ang default na entry ng table ay nangangailangan din ng via kasama ang gateway ng LAN sa ordinaryong link ng Ethernet; ang hubad na dev eth0 ay gumagana lamang kapag ang interface ay punto-sa-punto o ang susunod na hop ay nalutas sa ibang paraan. Ang iniulat na host na Jessie ay nasa isang link kung saan gumana ang hubad na anyo, at hindi iyon isang panuntunan ng distribusyon na dapat kopyahin.

I-verify nang hindi nakakulong sa labas

Huwag subukan sa pamamagitan ng pagkadiskonekta. Iwanang bukas ang unang sesyon, itaas ang tunnel, at itanong sa kernel kung aling daan ang tatahakin ng iyong sariling address:

ip route get 80.128.240.55

Dapat banggitin ng sagot ang pisikal na interface at lumang gateway, hindi ang tunnel. Pagkatapos ay buksan ang pangalawang koneksyon ng SSH; iyon ang tunay na pagsubok, dahil ang lumang sesyon ay maaaring mabuhay sa isang estado na hindi kayang kopyahin ng bagong koneksyon. Kung ang pangalawa ay nag-hang habang sumasagot pa ang una, hindi kailanman tumama ang panuntunan sa trapikong mahalaga, at ang mga marka o ang source address ang dapat tingnan.

Panatilihing magagamit ang isang console sa labas ng band sa buong pagsasanay. Ang server na ang tanging daan ng pag-access ay ang tunnel na kasisira mo lang ay hindi maaayos sa pamamagitan ng tunnel na iyon, at mas madali ang pag-atras kapag naisulat mo ang mga numero ng table at prefix na idinagdag mo.