OpenVPN rankos paspaudimas Synology nepavyksta? Patikrinkite LAN peradresavimą

Nešiojamasis kompiuteris praneša, kad TLS rankos paspaudimas nepavyko, todėl kyla pagunda perstatyti sertifikatus. Pirmiau užduokite nuobodulį keliantį klausimą: kuriame Ethernet prievade Synology iš tikrųjų klausosi? NAS su dviem LAN prievadais turi du adresus, o DSM VPN Server paketas pririša savo OpenVPN klausytoją prie vieno jų. Kai maršrutizatorius persiunčia 1194 į kitą adresą, nė vienas paketas niekada nepasiekia paslaugos, o klientas neturi su kuo derėtis.

Klaidos tekstas klaidina, nes aprašo paskutinį dalyką, kurį klientas bandė, o ne pirmąjį, kuris sugedo. Dviejų minučių palyginimas paketo puslapio su maršrutizatoriaus taisykle tai išsprendžia.

Raskite adresą, prie kurio pririštas klausytojas

DSM savo prievadus vadina LAN 1 ir LAN 2, ir kiekvienas turi atskirą adresą bei potinklį. Atidarykite VPN Server, perskaitykite sąsają, nurodytą OpenVPN skirtuke, tada atidarykite Valdymo skydą ir užsirašykite IPv4 adresą, kurį DSM turi toje pačioje sąsajoje. Būtent šias dvi reikšmes, o ne NAS pagrindinio kompiuterio vardą, turi nurodyti peradresavimas.

Antras prijungtas kabelis nesukuria antro klausytojo. Abi jungtys gali atrodyti prijungtos, nors srautą priima tik vienas adresas, o kai abi sąsajos yra tame pačiame potinklyje, du adresai skiriasi vienu skaitmeniu, kurio niekas iš naujo neperskaito prieš išsaugant taisyklę.

Pažiūrėkite į patį lizdą per SSH, nes tai vienintelė vieta, kuri parodo, prie ko daemonas iš tikrųjų prisirišo, o ne ką ketina nustatymų puslapis.

sudo netstat -anp | grep 1194

Redaguokite esamą peradresavimą, o ne pridėkite naują

Dvi taisyklės vienam išoriniam prievadui palieka maršrutizatoriui laisvę rinktis, o kurią jis pasirinks, gali pasikeisti po programinės įrangos atnaujinimo ar perkrovimo. Atidarykite jau esančią taisyklę, pakeiskite jos vidinį adresą, išsaugokite, tada vėl atidarykite ir perskaitykite reikšmę. Pavadinti taisyklę paslaugos vardu padeda, nes penkių vienodų peradresavimų sąrašas yra būdas, kuriuo neteisingas išlieka.

external 1194/udp  ->  192.0.2.20:1194/udp

Laikykite vidinį prievadą lygų klausymosi prievadui ir laikykite protokolą nuoseklų. UDP 1194 yra numatytasis klausytojas, o TCP profiliui reikia savo klausytojo paketo pusėje ir atitinkamo peradresavimo maršrutizatoriuje. Peradresavus TCP į paslaugą, kuri klausosi tik UDP, gaunama tyla, o ne klaida.

Jei NAS adresas gaunamas iš DHCP, rezervuokite jį prieš išsaugant taisyklę. Pasibaigus nuomai adresas priskiriamas iš naujo, peradresavimas tebėra nukreiptas į seną reikšmę, o rankos paspaudimas pradeda nepavyksta tą dieną, kai niekas nelietė NAS. Statinė konfigūracija NAS pusėje išsprendžia tą pačią problemą, jei adresas yra už maršrutizatoriaus DHCP diapazono ribų.

Įrodykite, ar paketai apskritai ateina

Pirmiausia pradėkite įrašymą NAS, tada prisijunkite iš kliento ir perskaitykite šaltinio adresą išvestyje. Įrašymas, pradėtas po gedimo, nieko nerodo ir nieko neįrodo.

sudo tcpdump -i any -n udp port 1194

Tyla reiškia, kad srautas mirė prieš paslaugą: neteisingas vidinis adresas, uždarytas prievadas DSM ugniasienėje arba administraciniu požiūriu išjungta sąsaja. Paketai išvestyje reiškia, kad peradresavimas veikia, o likęs gedimas yra aukščiau tinklo sluoksnio, o tai yra daug mažesnė paieškos sritis.

Įrašymas taip pat nurodo sąsają, kuria atėjo paketas, ir ši viena detalė atskiria taisyklę, nukreiptą į neteisingą prievadą, nuo taisyklės, nukreiptos į prievadą, kuris nėra įjungtas. Stebėkite paties maršrutizatoriaus skaitiklį per tą patį bandymą, jei jis jį rodo. Skaitiklis, kuris nejuda, kol įrašymas lieka tuščias, nurodo maršrutizatorių, o skaitiklis, kuris juda su tuščiu įrašymu, nurodo kelią tarp dviejų įrenginių.

Kai paketai ateina, nustokite kaltinti peradresavimą

Profilis yra kitas įtariamasis, o įprasta priežastis yra amžius. Eksportuotas .ovpn failas turi instituciją ir medžiagą nuo eksporto momento, todėl paketas, kurio sertifikatas vėliau buvo pakeistas, atmes klientą, kuris dar nešiojasi seną kopiją.

Transportas yra kitas neatitikimas, kurį verta tikrinti aiškiai, nes profilis ir paketas redaguojami skirtingose vietose. Pakeitus profilį iš UDP į TCP neperjungus paketo, klientas lieka laukti klausytojo, kurio nėra, ir klientas praneša tą patį bendrą rankos paspaudimo tekstą, kurį praneša viskam kitam. Perskaitykite proto eilutę faile, tada pažiūrėkite į serverio puslapyje pasirinktą protokolą ir tik tada darykite išvadą, kad jie sutampa. DSM ugniasienės taisyklių skaitymas yra trečioji patikra: taisyklę, leidžiančią prievadą iš vietinio potinklio, bet ne iš interneto, lengva palikti po testavimo, ir ji sukuria ryšį, kuris veikia iš virtuvės ir nepavyksta visur kitur.

Išbandykite kelią, kuriuo nuotolinis naudotojas iš tikrųjų eina

Klientas tame pačiame LAN gali pasiekti NAS niekada neliesdamas peradresavimo, todėl tai nieko neįrodo apie nuotolinę prieigą. Naudokite telefoną su išjungtu Wi-Fi arba paprašykite ko nors už tinklo ribų, ir stebėkite maršrutizatoriaus skaitiklį per tą bandymą. Jei nuotolinis bandymas nepavyksta, o vietinis pavyksta, peradresavimas arba ugniasienė vis dar dalyvauja.

Užsirašykite veikiančią būseną, kol ji veikia: išorinis prievadas, vidinis adresas, protokolas, paketo sąsaja, taip pat profilio pavadinimas ir eksporto data. Kai rankos paspaudimas vėl nepavyksta, skirtumas tarp to užrašo ir dabartinės konfigūracijos yra gedimas, ir niekam nereikia iš naujo atrasti, kurį iš dviejų prievadų naudoja paslauga.