Plena tunelo de OpenVPN fortranĉas vian SSH-sesion: riparu la vojon reen

Ŝalti OpenVPN-klienton kun plena tunelo sur maŝino, kiun vi atingas per SSH, povas fortranĉi la sesion ene de sekundo, kaj la maŝino faras nenion malbonan. La tunelo ne ŝanĝas kiel pakaĵoj atingas la servilon; ĝi ŝanĝas kiel la respondoj eliras. Tuj kiam la defa itinero montras al tun0, respondo al via SSH-kliento eniras la reton de la provizanto, kiu havas neniun itineron reen al via adreso. La konekto pendas, la sekva provo tempolimas, kaj la demono daŭre aŭskultas sur pordo 22 la tutan tempon.

Legu la itinertabelon antaŭ ol legi la protokolon de VPN. La protokolo diros, ke la tunelo leviĝis, kaj ĝi pravas. La demando estas, al kiu interfaco ĉiu respondo estas transdonata, kaj tio estas serĉo por ĉiu pakaĵo en tabelo, kiun la tunelo ĵus reskribis.

Kial la respondo eliras tra la malĝusta pordo

Envenantaj pakaĵoj ankoraŭ alvenas sur la fizikan interfacon, ĉar VPN-kliento ne povas ŝanĝi kiel la interreto atingas la publikan adreson de via servilo. Respondoj estas aparta decido: por ĉiu pakaĵo la kerno serĉas la celon, kaj post --redirect-gateway la defa ero diras tunelo. La elirejo de la provizanto vidas celon, kiun ĝi ne servas, kaj forĵetas la pakaĵon.

La propra protekto de OpenVPN kovras precize unu celon. La manlibro de 2.6 priskribas --redirect-gateway kiel sinsekvon: ĝi aldonas hostan itineron por la VPN-peer tra la pordego uzata antaŭ la tunelo, por ke la ĉifrita trafiko ne povu bukli reen en sin, kaj poste anstataŭigas la defan itineron. Tiu hosta itinero estas nur por la peer. Via SSH-kliento estas simple alia interreta adreso kaj ricevas neniun escepton.

Unu prefikseraron valoras ekskludi frue. ip route add -net 0.0.0.0 gw 10.8.0.1 dev tun0 sen longo kongruas kun la unuopa adreso 0.0.0.0, ne kun la interreto; ĝi devas esti 0.0.0.0/0. Kaj se preni la defan itineron rompas la propran transporton de la tunelo, aldonu la finan punkton kiel hostan itineron tra la fizika interfaco, uzante la realan adreson de la provizanto.

Fiksu la adreson de via SSH-kliento por tuja riparo

La plej rapida riparo estas hosta itinero por la adreso de via kliento tra la pordego, kiun la servilo uzis antaŭ ol ekzistis la tunelo. De via flanko, trovu la adreson, kiun la servilo vidos, poste legu la tabelon de la servilo por scii la malnovan pordegon:

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

Sur la servilo, aldonu la escepton antaŭ ol la kliento ekfunkcias. La adresoj ĉi tie estas lokokupiloj; la formo gravas:

sudo ip route add 80.128.240.55 via 192.168.178.1

Ĉi tio estas la riparo uzata en la raportita kazo, kaj ĝi funkcias tuj. Ĝi ankaŭ estas rompiĝema laŭ du antaŭvideblaj manieroj: la itinero malaperas ĉe restartigo, kaj ĝi fariĝas malĝusta en la momento, kiam via ISP donas al vi alian adreson. Traktu ĝin kiel urĝan rimedon kaj intence faru ĝin daŭra, per reta unuo aŭ hoko de la disĵetilo, aŭ akceptu, ke ĝi estas provizora, kaj skribu la reakiran vojon.

Malhelpu la klienton preni la defan itineron

La pli pura opcio estas malhelpi la tunelon anstataŭigi la defan itineron tute. route-nopull, uzata kun --client aŭ --pull, akceptas puŝitajn opciojn krom itineroj, block-outside-dns kaj DHCP-similaj opcioj kiel DNS-serviloj, do vi aldonas nur la prefiksojn, kiujn vi bezonas. Pli mallarĝa ilo estas eltira filtro, kiu forĵetas unu problemecan direktivon kaj konservas la reston:

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

Uzu unu aŭ la alian, ne ambaŭ, kaj estu klara pri tio, kio ŝanĝiĝas. Sen defa itinero tra la tunelo, la servilo ne plu retumas la interreton tra la provizanto; ĝi atingas nur tion, kion vi eksplicite itinigis. Se la plena tunelo estis la tuta celo de la agordo, ĉi tio estas la malĝusta butono kaj la hosta itinero supre estas la ĝusta.

Dividu la revenan vojon laŭ fonto aŭ laŭ konekto

Kiam la envenanta adreso estas stabila, fonta regulo tenas respondojn loke sen tuŝi la proprajn itinerojn de la tunelo. Donu al la adreso de la fizika interfaco sian propran tabelon enhavantan la LAN-prefikson kaj la fizikan defaĵon, poste elektu tiun tabelon por trafiko originanta de ĝi:

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

Ĉi tio funkcias ĉar respondoj al envenanta SSH-konekto originas de la adreso, al kiu la kliento konektiĝis. Raportita kazo, en kiu ĉiu envenanta servo devis daŭre funkcii, uzis precize ĉi tiun formon. Kiam la envenanta adreso ŝvebas aŭ la vojo estas dinamika, marku la konekton anstataŭe: starigu conntrack-markon sur la unuan pakaĵon alvenantan de la fizika interfaco, kopiu ĝin al respondaj pakaĵoj en OUTPUT, kaj itinigu markitajn pakaĵojn tra tabelo montranta al la fizika pordego.

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

Tenadu la konektomarkon, fajroŝirmilan markon kaj tabelnumeron apartaj dum testado. Reuzi unu numeron por du roloj produktas regulon, kiu aspektas ĝusta kaj trafas la malĝustajn pakaĵojn. La defa ero de la tabelo ankaŭ bezonas via kun la LAN-pordego sur ordinara Ethernet-ligilo; nuda dev eth0 funkcias nur kiam la interfaco estas punkto-al-punkto aŭ la sekva salto solviĝas alimaniere. La raportita gastiganto Jessie hazarde sidis sur ligilo, kie la nuda formo funkciis, kio ne estas distribua regulo por kopii.

Kontrolu sen ŝlosi vin ekstere

Ne testu per malkonektado. Tenu la unuan sesion malfermita, levu la tunelon, kaj demandu la kernon, kiun vojon via propra adreso irus:

ip route get 80.128.240.55

La respondo devus nomi la fizikan interfacon kaj la malnovan pordegon, ne la tunelon. Poste malfermu duan SSH-konekton; tio estas la vera testo, ĉar la malnova sesio povas postvivi sur stato, kiun nova konekto ne povas reprodukti. Se la dua pendas dum la unua ankoraŭ respondas, la regulo neniam trafis la trafikon, kiu gravas, kaj la markoj aŭ la fonta adreso estas kie rigardi.

Tenu eksterbandan konzolon disponebla dum la tuta ekzerco. Servilo, kies sola alirvojo estas la tunelo, kiun vi ĵus rompis, ne povas esti riparita tra tiu tunelo, kaj la restarigo estas pli facila, kiam vi notis la tabelnumerojn kaj prefiksojn, kiujn vi aldonis.