VPN klienti sasniedz serveri, bet ne LAN tīklu: kurš risinājums?

Klients pingē OpenVPN servera tuneļa adresi un saņem atbildi, pēc tam mēģina saimnieku servera LAN tīklā un nesaņem neko. Šī atšķirība ievērojami sašaurina kļūdu: tunelis ir pacelts, pārsūtīšana, visticamāk, darbojas, un atbilde iziet pa durvīm, kas neved atpakaļ. Ir trīs risinājumi, un pareizais atkarīgs no tā, ko jūs kontrolējat un no kā esat gatavs atteikties. Atbildiet uz trim jautājumiem zemāk pēc kārtas, un izvēle vairs nebūs gaumes jautājums.

Vispirms noskaidrojiet, kurš virziens ir salūzis

Pieprasījums ienāk tuneļa saskarnē ar avota adresi no VPN pūla. Serveris to pārsūta uz LAN tīkla saimnieku, un šis saimnieks atbild vārtejai, ko nosauc viņa paša tabula, parasti LAN tīkla maršrutētājam. Ja maršrutētājam nav maršruta uz pūlu, atbilde tur nomirst vai klejo pretī internetam.

Pārbaudiet abas mašīnas, pirms maināt jebkuru. Pajautājiet serverim, pa kuru ceļu viņa tabula nokļūtu līdz klientam; pajautājiet LAN tīkla saimniekam, kā viņš nokļūtu līdz tai pašai adresei. Pirmā meklēšana parasti norāda uz tuneli, bet otrā uz LAN tīkla maršrutētāju, un šī atšķirība ir kļūda vienā rindā. Divas meklēšanas ir lētākas par ugunsmūra auditu, un tās nosaka problēmas virzienu.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Ja LAN tīkla saimnieks jau norāda uz VPN serveri, jūsu problēma ir ugunsmūra noteikums vai MTU ierobežojums, nevis trūkstošs atgriešanās ceļš. Nepievienojiet maršrutu, lai salabotu filtru.

Pirmais jautājums: vai jūs varat rediģēt tālā LAN tīkla maršrutētāju?

Kad LAN tīkla maršrutētājs ir jūsu, tīra atbilde ir statisks maršruts uz VPN pūlu ar VPN servera LAN adresi kā nākamo lēcienu. Tas saglabā klientu avota adreses neskartas, kas ir svarīgi, kad LAN tīkla saimnieki žurnalē, filtrē vai ierobežo joslas platumu pēc adreses. Tam arī nav vajadzīgs tulkojums serverī, tāpēc tunelis paliek tīrs maršrutēšanas ceļš. Saistības, ko tas rada, ir dokumentācija, jo pūlam, maršrutam un servera konfigurācijai jāsakrīt.

Tas klusi neizdodas tajā dienā, kad kāds maina pūlu. Pierakstiet vērtību vienreiz un uzskatiet izmaiņas jebkurā no trim vietām par izmaiņām visās trijās.

NAS vai Layer 3 komutators, kas mitina pakalpojumu, pieprasa to pašu maršrutu, ja vien tas visu nesūta caur maršrutētāju, kuram tas ir. Pārbaudiet ierīci, kas pabeidz apakštīklu, ne tikai to, kas vērsta pret internetu. Mazos tīklos bieži ir trīs ierīces ar viedokli par maršrutēšanu.

Otrais jautājums: vai LAN tīkls var pārstāt redzēt klientu adreses?

Kad maršrutētājs pieder kādam citam, tulkošana uz VPN servera neprasa sadarbību. LAN tīkla saimnieks redz servera LAN adresi, atbild tai, un serveris pārtulko atpakaļ. Tāpēc ierīces un uz NAT balstītās attālinātās piekļuves lomas uzvedas tieši tā.

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

Cena ir attiecināšana: adreses uz klientu pazūd no LAN tīkla žurnāliem. Jebkuram atļauto sarakstam LAN tīkla saimniekā tad jānosauc serveris, nevis pūls.

Izvēlieties tulkošanu, kad sadarbība nav pieejama, nevis kad tā ir vienkārši neērta. Tā slēpj klientu no katras turpmākās izmeklēšanas, arī tām, kur jums jāzina, kurš portatīvais dators atvēra savienojumu. Tā var arī salauzt protokolus, kas iegulst adreses lietderīgajā kravā, jo tulkojums dzīvo galvenē. Neviena iespēja nav progresīvāka; tās atbild uz dažādiem jautājumiem par īpašumtiesībām.

Trešais jautājums: vai serveris pats ir cita tuneļa klients?

Iedomājieties otru topoloģiju: VPN serveris zvana arī komerciālam pakalpojumu sniedzējam, tāpēc tam ir divi tuneļi un divas adrešu kopas. Satiksme, ko tas pārsūta saviem klientiem, iziet caur sniedzēju, un tas nenovirzīs atbildes atpakaļ uz pūla adresēm. Tāpēc atbildes pazūd, lai gan abi tuneļi ir veseli.

Risinājums ir maskēt arī izejošo tuneli, lai sniedzējs redzētu tikai servera tuneļa adresi. Pretējam virzienam vajag savu noteikumu, jo serveris, kas sāk savienojumu uz savu klientu, ir cita plūsma. Bez šī noteikuma klients atbild uz adresi, kuru nevar maršrutēt. Novietojiet šauro noteikumu pirms jebkuras plašas maskēšanas, lai uzvarētu konkrētais tulkojums.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

Saimnieki ar vairākām saskarnēm pievieno radniecisku kļūdu, kas no klienta puses izskatās vienādi. Atbilde iziet pa saskarni ar zemāku metriku, jo avota adrese tika izvēlēta no citas tabulas. Pārbaudiet atgriešanās ceļu ar meklēšanu, nevis pieņemiet, ka gaitas ceļš to ietver.

Pēc tam pārbaudiet abus virzienus un abus izmērus

Pēc izmaiņām pingējiet no klienta uz LAN tīkla saimnieku un pēc tam no LAN tīkla saimnieka uz klientu. Otrais virziens ir tas, ko cilvēki izlaiž, un tas atklāj nepilnīgu tulkošanas noteikumu. Pierakstiet abus rezultātus ar laika zīmogu, lai vēlāka regresija būtu salīdzināma.

Pēc tam pārvietojiet īstus datus, jo mazs pings, kas izdodas, kamēr liels pārvades process apstājas, ir MTU simptoms. Šī kļūda parādās tūlīt pēc tam, kad esat apsveicis sevi ar salabotu maršrutu.

Visbeidzot pārbaudiet vēlreiz pēc pārstartēšanas. Maršruta un ugunsmūra komandas darbības laikā to nepārdzīvo, un labojums, kas pazūd nākamajā startā, tiks diagnosticēts no jauna ar kādu ar mazāk konteksta. Padariet izmaiņas pastāvīgas tā, kā jūsu sistēma jau dara, un pēc tam vienreiz apzināti pārstartējiet.