Regulo de aŭskultanto en firewalld kontraŭ plusenda politiko: kion faras ĉiu

VPN, kiu konektiĝas sed atingas nenion, estas kutime priskribata kiel fajroŝirma problemo, kaj la solvo, al kiu homoj sin turnas, estas meti la tunelan interfacon en fidatan zonon. Tio funkcias en la senco, ke trafiko komencas flui, sed ĝi ankaŭ permesas multe pli ol la celita servo. La du koncernaj politikoj malsamas: unu permesas la eksteran transporton al aŭskultanta ingo, kaj la alia rajtigas malĉifritan trafikon atingi specifan rimedon. Trakti ilin kiel unu agordon estas tio, kio igas mallarĝan permeson larĝa. Ambaŭ decidiĝas en malsamaj lokoj, kaj tial la eraro estas tiel facila.

Du politikoj, unu tunelo

La ekstera politiko respondas simplan demandon: ĉu paketo el ĉi tiu fonto rajtas atingi UDP 1194 sur ĉi tiu gastiganto? La interna politiko respondas alian: ĉu la aŭtentikigita kliento malantaŭ tiu tunelo rajtas atingi ĉi tiun celon, per ĉi tiu protokolo, sur ĉi tiu pordo? La unua temas pri ingo, la dua pri vojo, kaj firewalld modelas ilin per malsamaj objektoj, ĉar ili decidiĝas en malsamaj punktoj. Unu estas eco de ingo sur ĉi tiu gastiganto, la alia de vojo tra ĝi.

La praktika sekvo estas, ke funkcianta tunelo diras nenion pri la dua politiko, kaj ĝusta dua politiko ne igas la unuan superflua.

Permesu la realan eksteran aŭskultanton

Komencu per ekzameno de tio, kio jam estas asignita, anstataŭ supozi. Legu la aktivajn zonojn, listigu la zonon, kiu efektive portas envenan trafikon, kaj kontrolu la instalitan servan difinon, ĉar serva nomo priskribas aron da pordoj kaj diras nenion pri tio, ĉu la aŭskultanto de ĉi tiu servilo kongruas kun ĝi.

firewall-cmd --get-active-zones
firewall-cmd --zone=public --list-all
firewall-cmd --info-service=openvpn

Se la aŭskultanto efektive estas UDP 1194 en tiu zono, malfermu precize tiun pordon kaj transporton, poste igi la saman specifan regulon daŭra post kiam vi testis ĝin. Kontrolu ankaŭ font-bazitajn asignojn, ĉar zono ligita al fonta gamo povas kapti la trafikon antaŭ ol la interfaĉa zono eĉ vidas ĝin.

Rajtigu la malĉifritan celon aparte

Konekto al servo kuranta sur la VPN-servilo mem estas loka-eniga politiko. Konekto plusendata al alia gastiganto en la LAN bezonas plusendan politikon, plusendadon ŝaltitan en la kerno kaj respondan vojon — tri apartaj postuloj, kiujn homoj kutime kunfandas en unu. Modernaj politikaj objektoj de firewalld priskribas direktitan trafikon inter envena zono kaj elvena zono, kaj tio estas la ĝusta loko por esprimi, kiuj VPN-fontoj rajtas atingi kiujn privatajn servojn.

Difinu la permesitajn fontojn eksplicite kaj lasu ĉion alian fali en malpermeson. Permeso por la ekstera servo ne estas tiu politiko, kiel ajn la zona aranĝo aspektas.

Kial fidi la interfacon estas la malĝusta fuŝsolvo

Meti la tunelan interfacon en zonon, kies celo akceptas ĉion, permesas ĉiun malĉifritan trafikon al ĉiu servo, kiun la gastiganto elmetas, inkluzive de tiuj, kiujn vi ne reviziis. Rekanceligi la fidatan zonon por esti limiga sur funkcianta maŝino estas pli malbone, ĉar aliaj interfacoj kaj fontaj gamoj eble jam dependas de ĝia signifo kaj ŝanĝos konduton, kiam vi redaktos ĝin. Se vi bezonas mallarĝan politikon, kreu unu; ne reuzu komunan zonon.

Ankaŭ tenu stabila la zonan asignon de la tunelo per kiu ajn komponento posedas tiun agordon. Perdi la asignon ĉe restarto produktas fiaskon, kiu aspektas kiel problemo de fajroŝirma regulo kaj efektive estas problemo de daŭreco.

Kontrolu tri aferojn, inkluzive de unu malpermeso

Testu la eksteran konekton de ekstere, testu unu rajtigitan internan servon de konektita kliento, kaj testu unu servon, kiu devus resti neatingebla. La tria testo estas tiu, kiu distingas politikon disde kromefiko, kaj ĝin homoj preterlasas, ĉar ĉio ŝajnas funkcii. Se la malpermesita servo respondas, vi permesis zonon anstataŭ servon.

Notu la zonon, pordon, transporton kaj politikan objekton en la notoj de la servilo. Alie la sekva ŝanĝo sur ĉi tiu gastiganto komenciĝos de la sama supozo.