Ieslēdzot pilna tuneļa OpenVPN klientu mašīnā, kurai piekļūstat caur SSH, sesija var pārtrūkt sekundes laikā, un mašīna nedara neko nepareizi. Tunelis nemaina to, kā paketes sasniedz serveri; tas maina to, kā iziet atbildes. Tiklīdz noklusējuma maršruts norāda uz tun0, atbilde jūsu SSH klientam nonāk pakalpojumu sniedzēja tīklā, kuram nav maršruta atpakaļ uz jūsu adresi. Savienojums uzkaras, nākamais mēģinājums beidzas ar taimautu, un dēmons visu laiku klausās portā 22.

Izlasi maršrutēšanas tabulu pirms VPN žurnāla lasīšanas. Žurnāls teiks, ka tunelis ir pacēlies, un tam būs taisnība. Jautājums ir, kurai saskarnei tiek nodota katra atbilde, un tas ir meklējums katram paketei tabulā, kuru tunelis tikko pārrakstīja.

Kāpēc atbilde iziet pa nepareizajām durvīm

Ienākošās paketes joprojām pienāk fiziskajā saskarnē, jo VPN klients nevar mainīt to, kā internets sasniedz jūsu servera publisko adresi. Atbildes ir atsevišķs lēmums: katrai paketei kodols meklē galamērķi, un pēc --redirect-gateway noklusējuma ieraksts saka tunelis. Pakalpojumu sniedzēja izeja redz galamērķi, kuru neapkalpo, un izmet paketi.

OpenVPN paša aizsardzība sedz tieši vienu galamērķi. 2.6 rokasgrāmata apraksta --redirect-gateway kā secību: tā pievieno resursdatora maršrutu VPN peer caur vārteju, kas tika izmantota pirms tuneļa, lai šifrētā plūsma nevarētu atgriezties pašā sevī, un pēc tam aizstāj noklusējuma maršrutu. Šis resursdatora maršruts ir tikai peer. Jūsu SSH klients ir tikai vēl viena interneta adrese un nesaņem nekādu izņēmumu.

Vienu prefiksa kļūdu ir vērts izslēgt agri. ip route add -net 0.0.0.0 gw 10.8.0.1 dev tun0 bez garuma atbilst vienai adresei 0.0.0.0, nevis internetam; tam jābūt 0.0.0.0/0. Un, ja noklusējuma pieņemšana salauž paša tuneļa transportu, pievienojiet galapunktu kā resursdatora maršrutu caur fizisko saskarni, izmantojot pakalpojumu sniedzēja īsto adresi.

Piespraudiet sava SSH klienta adresi tūlītējai labošanai

Ātrākais labojums ir resursdatora maršruts jūsu klienta adresei caur vārteju, ko serveris izmantoja pirms tuneļa. No savas puses atrodiet adresi, ko serveris redzēs, pēc tam izlasiet servera tabulu, lai zinātu veco vārteju:

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

Serverī pievienojiet izņēmumu pirms klienta starta. Adreses šeit ir vietturi; forma ir svarīga:

sudo ip route add 80.128.240.55 via 192.168.178.1

Šis ir labojums, kas izmantots ziņotajā gadījumā, un tas darbojas uzreiz. Tas ir arī trausls divos paredzamos veidos: maršruts pazūd pēc pārstartēšanas, un tas kļūst nepareizs tajā brīdī, kad jūsu ISP jums piešķir citu adresi. Uztveriet to kā ārkārtas pasākumu un apzināti padariet to ilgstošu, izmantojot tīkla vienību vai dispatcher āķi, vai pieņemiet, ka tas ir pagaidu, un pierakstiet atjaunošanas ceļu.

Neļaujiet klientam paņemt noklusējuma maršrutu

Tīrāka iespēja ir neļaut tunelim aizstāt noklusējuma maršrutu vispār. route-nopull, lietots kopā ar --client vai --pull, pieņem stumtos parametrus, izņemot maršrutus, block-outside-dns un DHCP stila parametrus, piemēram, DNS serverus, tāpēc jūs pievienojat tikai nepieciešamos prefiksus. Šaurāks instruments ir vilkšanas filtrs, kas izmet vienu problemātisku direktīvu un patur pārējo:

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

Izmantojiet vienu vai otru, nevis abus, un skaidri ziniet, kas mainās. Bez noklusējuma maršruta caur tuneli serveris vairs nepārlūko internetu caur pakalpojumu sniedzēju; tas sasniedz tikai to, ko esat skaidri maršrutējis. Ja pilns tunelis bija viss iestatījuma mērķis, tas ir nepareizais slēdzis, un augstāk minētais resursdatora maršruts ir pareizais.

Sadaliet atgaitas ceļu pēc avota vai savienojuma

Kad ienākošā adrese ir stabila, avota noteikums patur atbildes lokāli, neaizskarot paša tuneļa maršrutus. Dodiet fiziskās saskarnes adresei savu tabulu ar LAN prefiksu un fizisko noklusējumu, pēc tam izvēlieties šo tabulu no tās nākošajai plūsmai:

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

Tas darbojas, jo atbildes uz ienākošo SSH savienojumu nāk no adreses, kurai klients pievienojās. Ziņotais gadījums, kurā katram ienākošajam pakalpojumam bija jāturpina darboties, izmantoja tieši šo formu. Kad ienākošā adrese ir plūstoša vai ceļš ir dinamisks, atzīmējiet savienojumu: uzlieciet conntrack atzīmi pirmajai paketei, kas nāk no fiziskās saskarnes, nokopējiet to uz atbildes paketēm OUTPUT, un maršrutējiet atzīmētās paketes caur tabulu, kas norāda uz fizisko vārteju.

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

Testēšanas laikā turiet savienojuma atzīmi, ugunsmūra atzīmi un tabulas numuru atsevišķi. Viena numura izmantošana divām lomām rada noteikumu, kas izskatās pareizi un trāpa nepareizajām paketēm. Tabulas noklusējuma ierakstam arī vajag via ar LAN vārteju parastā Ethernet saitē; kails dev eth0 darbojas tikai tad, ja saskarne ir punkts-punktā vai nākamais lēciens tiek atrisināts citādi. Ziņotais Jessie resursdators nejauši atradās saitē, kur kailā forma darbojās, un tā nav izplatīšanas noteikums, ko kopēt.

Pārbaudiet, neaizslēgdamies

Nepārbaudiet, atslēgdamies. Turiet pirmo sesiju atvērtu, paceliet tuneli un pajautājiet kodolam, kādu ceļu ietu jūsu paša adrese:

ip route get 80.128.240.55

Atbildei jānosauc fiziskā saskarne un vecā vārteja, nevis tunelis. Pēc tam atveriet otru SSH savienojumu; tas ir īstais tests, jo vecā sesija var izdzīvot stāvoklī, ko jauns savienojums nevar atjaunot. Ja otrā uzkaras, kamēr pirmā vēl atbild, noteikums nekad nav trāpījis svarīgajai plūsmai, un atzīmes vai avota adrese ir vieta, kur jāmeklē.

Visas apmācības laikā turiet pieejamu ārpusjoslas konsoli. Serveri, kura vienīgais piekļuves ceļš ir tikko salauztais tunelis, nevar salabot pa šo tuneli, un atritināšana ir vieglāka, ja esat pierakstījis pievienotos tabulas numurus un prefiksus.

Saistītie raksti