VPN, mis ühendub, kuid ei jõua kuhugi, kirjeldatakse tavaliselt tulemüüri probleemina ja lahendus, mille poole inimesed pöörduvad, on tunneliliidese paigutamine usaldusväärsesse tsooni. See töötab selles mõttes, et liiklus hakkab liikuma, kuid lubab ka palju enamat kui kavandatud teenus. Kaks asjasse puutuvat poliitikat on erinevad: üks lubab välistranspordi kuulavasse soklisse ja teine volitab dekrüpteeritud liikluse jõudma konkreetse ressursini. Just nende käsitlemine ühe seadistusena muudab kitsa loa laiaks. Mõlemad otsustatakse erinevates kohtades, mistõttu on viga nii lihtne teha.

Kaks poliitikat, üks tunnel

Väline poliitika vastab lihtsale küsimusele: kas selle allika pakett võib jõuda UDP 1194-ni selles hostis? Sisemine poliitika vastab teisele: kas selle tunneli taga olev autenditud klient võib jõuda selle sihtkohani, selle protokolliga, sellel pordil? Esimene puudutab soklit, teine teed, ja firewalld modelleerib neid erinevate objektidega, sest need otsustatakse erinevates punktides. Üks on selle hosti sokli omadus, teine sellest läbiva tee omadus.

Praktiline tagajärg on see, et töötav tunnel ei ütle teise poliitika kohta midagi ja õige teine poliitika ei muuda esimest üleliigseks.

Lubage tegelik väline kuular

Alustage selle uurimisest, mis on juba määratud, mitte oletamisest. Lugege aktiivsed tsoonid, loetlege tsoon, mis tegelikult sissetulevat liiklust kannab, ja kontrollige paigaldatud teenuse määratlust, sest teenuse nimi kirjeldab portide kogumit ega ütle midagi selle kohta, kas selle serveri kuular sellega ühtib.

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

Kui kuular on tõesti UDP 1194 selles tsoonis, avage täpselt see port ja transport, seejärel muutke sama konkreetne reegel püsivaks pärast selle testimist. Kontrollige ka allikapõhiseid määranguid, sest allikavahemikuga seotud tsoon võib liikluse kinni püüda enne, kui liidese tsoon seda üldse näeb.

Volitage dekrüpteeritud sihtkoht eraldi

Ühendus VPN-serveri enda peal töötava teenusega on kohaliku sisendi poliitika. Ühendus, mis edastatakse teisele hostile LAN-is, vajab edastuspoliitikat, tuumakeses lubatud edastust ja vastusteet — need on kolm eraldi nõuet, mille inimesed tavaliselt üheks kokku suruvad. Kaasaegsed firewalld poliitikaobjektid kirjeldavad suunatud liiklust sissetuleva ja väljuva tsooni vahel ning see on õige koht väljendamaks, millised VPN-i allikad võivad jõuda milliste privaatsete teenusteni.

Määratlege lubatud allikad selgesõnaliselt ja laske kõigel muul langeda keeldumisse. Välise teenuse luba ei ole see poliitika, ükskõik kuidas tsoonide paigutus ka ei paista.

Miks liidese usaldamine on vale otsetee

Tunneliliidese paigutamine tsooni, mille sihtmärk võtab vastu kõike, lubab kogu dekrüpteeritud liikluse igasse teenusesse, mida host pakub, sealhulgas neisse, mida te ei ole üle vaadanud. Usaldusväärse tsooni ümbersuunamine piiravaks töötaval masinal on hullem, sest teised liidesed ja allikavahemikud võivad juba selle tähendusest sõltuda ja muudavad käitumist, kui te seda muudate. Kui vajate kitsast poliitikat, looge see; ärge kasutage jagatud tsooni uuel eesmärgil.

Hoidke ka tunneli tsoonimäärang stabiilsena ükskõik millise komponendi kaudu, mis seda konfiguratsiooni omab. Määrangu kaotamine taaskäivitamisel tekitab tõrke, mis näeb välja nagu tulemüüri reegli probleem ja on tegelikult püsivuse probleem.

Kontrollige kolme asja, sealhulgas ühte keeldumist

Testige välist ühendust väljastpoolt, testige ühte volitatud sisemist teenust ühendatud kliendist ja testige ühte teenust, mis peaks jääma kättesaamatuks. Kolmas test on see, mis eristab poliitikat kõrvalmõjust, ja just selle jätavad inimesed vahele, sest kõik näib töötavat. Kui keelatud teenus vastab, olete lubanud tsooni, mitte teenuse.

Kirjutage tsoon, port, transport ja poliitikaobjekt serveri märkmetesse. Vastasel juhul algab järgmine muudatus selles hostis samast oletusest.

Seotud artiklid