Pravilo poslušalca v firewalld proti politiki posredovanja: kaj počne katero

VPN, ki se poveže, a ne doseže ničesar, običajno opišemo kot težavo požarnega zidu, in rešitev, po katero ljudje posežejo, je, da vmesnik tunela postavijo v zaupanja vredno območje. To deluje v smislu, da promet začne teči, a prepušča tudi veliko več kot predvidena storitev. Dve vpleteni politiki sta različni: ena prepusti zunanji promet do poslušajoče vtičnice, druga avtorizira dešifriran promet, da doseže določen vir. Prav obravnavanje obeh kot ene nastavitve spremeni ozko dovoljenje v široko. Obe se odločata na različnih mestih, zato je napaka tako lahka.

Dve politiki, en tunel

Zunanja politika odgovarja na preprosto vprašanje: sme paket iz tega vira doseči UDP 1194 na tem gostitelju? Notranja politika odgovarja na drugo: sme overjeni odjemalec za tem tunelom doseči ta cilj, s tem protokolom, na teh vratih? Prva je o vtičnici, druga o poti, in firewalld ju modelira z različnimi objekti, ker se odločata na različnih točkah. Ena je lastnost vtičnice na tem gostitelju, druga lastnost poti skozi njega.

Praktična posledica je, da delujoč tunel ne pove ničesar o drugi politiki, in pravilna druga politika ne naredi prve odveč.

Spustite resničnega zunanjega poslušalca

Začnite s pregledom tega, kar je že dodeljeno, namesto s predpostavko. Preberite aktivna območja, naštejte območje, ki dejansko nosi dohodni promet, in preverite nameščeno definicijo storitve, ker ime storitve opisuje nabor vrat in ne pove ničesar o tem, ali se poslušalec tega strežnika z njim ujema.

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

Če je poslušalec res UDP 1194 v tem območju, odprite prav ta vrata in promet, nato pa po preizkusu naredite isto konkretno pravilo trajno. Preverite tudi dodelitve na podlagi vira, ker lahko območje, vezano na obseg virov, ujame promet, preden ga območje vmesnika sploh vidi.

Avtorizirajte dešifrirani cilj ločeno

Povezava do storitve, ki teče na samem strežniku VPN, je politika lokalnega vhoda. Povezava, posredovana drugemu gostitelju v LAN, potrebuje politiko posredovanja, posredovanje, omogočeno v jedru, in povratno pot — tri ločene zahteve, ki jih ljudje pogosto zlijejo v eno. Sodobni objekti politik firewalld opisujejo usmerjen promet med vhodnim in izhodnim območjem, in prav tam je pravo mesto za izraziti, kateri viri VPN smejo doseči katere zasebne storitve.

Dovoljene vire določite izrecno in pustite vsemu drugemu, da pade v zavrnitev. Dovoljenje za zunanjo storitev ni ta politika, ne glede na to, kako je videti razporeditev območij.

Zakaj je zaupanje v vmesnik napačna bližnjica

Postavitev vmesnika tunela v območje, katerega cilj sprejema vse, prepusti ves dešifriran promet do vsake storitve, ki jo gostitelj izpostavi, tudi tistih, ki jih niste pregledali. Preusmeritev zaupanja vrednega območja v omejevalno na delujočem stroju je slabša, ker so drugi vmesniki in obsegi virov morda že odvisni od njegovega pomena in bodo spremenili vedenje, ko ga uredite. Če potrebujete ozko politiko, jo ustvarite; ne uporabite znova skupnega območja.

Ohranjajte tudi dodelitev območja tunela stabilno prek katere koli komponente, ki ima to konfiguracijo. Izguba dodelitve ob ponovnem zagonu povzroči napako, ki je videti kot težava s pravilom požarnega zidu, v resnici pa je težava s trajnostjo.

Preverite tri stvari, vključno z eno zavrnitvijo

Preizkusite zunanjo povezavo od zunaj, preizkusite eno avtorizirano notranjo storitev s povezanega odjemalca in preizkusite eno storitev, ki bi morala ostati nedosegljiva. Tretji preizkus je tisti, ki loči politiko od stranskega učinka, in prav tega ljudje izpustijo, ker se zdi, da vse deluje. Če zavrnjena storitev odgovori, ste spustili območje in ne storitve.

Zapišite območje, vrata, promet in objekt politike v zapiske strežnika. Drugače se bo naslednja sprememba na tem gostitelju začela z isto predpostavko.