OpenVPN klients sasniedz serveri, bet ne LAN saimniekus: kontrolsaraksts

Klients ziņo, ka ir savienots, tuneļa adrese atbild uz ping, un biroja LAN tīklā nekas neatbild. Es to redzu pēc gandrīz katra klienta atjauninājuma, un pirmā sajūta ir atvērt ugunsmūri, kas parasti ir nepareizais solis: tunelis ir kārtībā, un pārrāvums ir vienā no trim lēcieniem, kas paketei jāšķērso. Ejiet pa ceļu tādā secībā, kādā pakete iet, vispirms klienta maršruts, tad servera pārsūtīšana, tad atgriešanās ceļojums, un pāris minūtēs atradīsiet kļūmes saimnieku.

Pirmais solis: vērojiet klienta maršrutēšanas lēmumu

Pirms aiztiekat serveri, pierādiet, ka klients sūta paketi tunelī. Pajautājiet kodolam, kuru saskarni tas izmantotu vienam konkrētam LAN saimniekam, tā vietā lai lasītu visu tabulu:

ip route get 192.168.50.10

Ja atbilde nosauc jūsu fizisko adapteri un biroja vārteju, nekādas izmaiņas servera pusē nepalīdzēs. OpenVPN izdala maršrutus tikai tad, kad serveris tos bīda, tāpēc meklējiet push "route 192.168.50.0 255.255.255.0" servera konfigurācijā un pēc tam atkārtoti pievienojiet klientu. Lielākā daļa klientu bīdītos maršrutus piemēro savienošanās laikā, nevis tad, kad pārlādējat profilu.

Windows sistēmā uz to pašu jautājumu ir cita komanda. Find-NetRoute -RemoteIPAddress 192.168.50.10 izdrukā saskarni un nākamo lēcienu, ko izvēlētos steks, un route print -4 parāda, vai bīdītais prefikss vispār pastāv.

Otrais solis: apstipriniet, ka serveris pārsūtīs paketi

Ja klienta maršruts ir pareizs, pakete sasniedz serveri, un serverim jāpiekrīt to pārsūtīt. Kodola slēdzis ir pirmie vārti, un sysctl net.ipv4.ip_forward jāatgriež 1. Iestatīšana ar echo 1 > /proc/sys/net/ipv4/ip_forward darbojas līdz nākamajai pārstartēšanai, un tieši tāpēc tā pati sūdzība atgriežas nedēļas vēlāk.

Pierakstiet to vietā, kas pārdzīvo pārstartēšanu:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

Otrie vārti ir filtra tabula. Saimniekam ar instalētu Docker bieži ir FORWARD politika DROP, un tunelis šo lēmumu manto. iptables -L FORWARD -v -n parāda gan politiku, gan pakešu skaitītājus; ja politika ir DROP, pārsūtīšanai vajag skaidru atļauju virzienam no tuneļa uz LAN un vēl vienu atbildei.

Trešais solis: sekojiet paketei uz LAN un meklējiet atbildi

Vērojiet abas servera puses vienlaikus. Ierakstiet tunelī un LAN saskarnē, filtrējot uz vienu klientu un vienu saimnieku, lai izvade paliktu lasāma:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

Pieprasījumi, kas parādās tun0 un atkal eth0 ar avotu 10.8.0.x, kam seko klusums, nozīmē, ka pakete ieradās un atbilde aizgāja citur. LAN saimnieks atbild savai noklusējuma vārtejai, tai vārtejai nav maršruta uz VPN pūlu, un atbilde mirst LAN maršrutētājā. Pingot LAN saimnieku no servera neko nepierāda par šo ceļu, jo tas trafiks nekad nešķērso tuneli.

Ceturtais solis: izvēlieties starp tulkošanu un atgriešanās maršrutu

Divi labojumi aizver caurumu, un izvēlei ir sekas ārpus tā, vai ping strādā. Avota tulkošana padara serveri par šķietamo sūtītāju:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Ierobežojiet noteikumu ar pūlu un LAN saskarni, pēc tam padariet to pastāvīgu, citādi nākamā ugunsmūra pārlāde klusi noņems jūsu labojumu. Cena ir identitāte: katrs klients LAN žurnālos un piekļuves noteikumos izskatās kā VPN serveris, un per-client policy becomes guesswork.

Statisks maršruts 10.8.0.0/24 tīklam LAN maršrutētājā, kas norāda uz VPN serveri, saglabā klientu adreses redzamas un ir labāka ilgtermiņa atbilde, ja tas maršrutētājs ir jūsu. Daudzas vietas kādu laiku darbina abus, NAT tūlītējam labojumam un maršrutu, tiklīdz ugunsmūra politika ir uzrakstīta. Ja serveris ir site-to-site partneris, nevis pūls, servera pusei arī vajag iroute attālajam apakštīklam, citādi partnera maršruts pastāv, bet klientu trafiks ar to nekad netiek saistīts.

Piektais solis: pārbaudiet no klienta un pierakstiet, kas mainījās

Aizveriet cilpu no klienta, nevis no servera. Pieslēdzieties īstam servisam LAN saimniekā, pēc tam apstipriniet, ka tulkošanas skaitītāji ir pavirzījušies ar iptables -t nat -L POSTROUTING -v -n, jo noteikums bez pakešēm ir noteikums, kas nekad nav saskaņojies. conntrack -L -s 10.8.0.5 parāda plūsmu un tās stāvokli, kad vajag pierādījumu, ka atgriešanās virziens tiek izsekots.

Atstājiet piezīmi servera konfigurācijā: kurš apakštīkls, kura saskarne, kurš noteikums un vai LAN maršrutētājam ir atgriešanās maršruts. Nākamreiz, kad klienta atjauninājums izdzēsīs bīdīto maršrutu, šī piezīme pārvērtīs ugunsgrēka dzēšanas sesiju vienas rindas labojumā.