OpenBSD - orosz - pfctl -ef minden újraindítás után
openbsd 4.5 a hiba minden javításával
Probléma: minden egyes újraindítás után kézzel kell ragaszkodnia
az ssh-on és a chop pfctl -ef /etc/pf.conf fájlban, különben a NAT nem működik,
és az interfészek közötti csomagokat nem irányítják.
Senki sem szembesült ezzel? A beállítások szerint mindent leírtak
helyesen tetszik. És önmagában a pf működik, ahogy kellene
(NAT / útválasztás és TP). Már legalább a pf-t el kell kezdeni,
és a pf.conf jogosultságai helyesek, és nincsenek hibák a konfigurációban. olvastam
valahol, hogy a kernel újraépítése az ipv6-tal letiltja a pf,
de ez nem az én esetem (nem értem az ipv6-ot). A részletek az alábbiak. Köszönöm.
# diff ./GENERIC ./MYCONF
13c13
> tartalmazza a "../../../conf/MYCONF"
34c34
<#option NTFS # Experimental NTFS support
---
> NTFS # Experimental NTFS támogatás
# diff. /../../conf/GENERIC. /../../conf/MYCONF; echo $?
0
# ls -l /etc/pf.conf
-rw ------- 1 gyökér kerék 1989 szept. 30 23:29 /etc/pf.conf
# cat /etc/rc.conf | grep pf
ospfd_flags = NO # normál használat esetén: ""
ospf6d_flags = NO # normál használat esetén: ""
pf = NO # Csomagszűrő / NAT
pf_rules = / etc / pf.conf # Csomagszűrő szabályfájl
pflogd_flags = # add több zászlót, pl. "-s 256"
# cat /etc/rc.conf.local | grep pf
pf = IGEN
# pfctl -nf /etc/pf.conf; echo $?
0
a manuális indítás után a pfctl -ef /etc/pf.conf minden működik.
Ne csattanjon a csípőjével a rendszerindításkor, és nézze meg, miért pfctl
elutasította, hogy a pf.conf-ot lenyomja.
vagy átgondolva elolvashatóan, a dns nevek témájára (akkoriban)
akkor kezdődik, amikor a pfctl szinte mindig elnevezett még nem lett szinkronizálva), mindenki
tun'ov (ami még mindig hülye a pfctl pillanatában) és így tovább.
pfctl -ef a tail rc.local-ban. nem elegendő.
füst pf.conf a megvilágosodás előtt, miért nem duplex pfctl rendszeren
kiszámíthatja, hogy vannak szintaktikai hibák
Nyissa meg ezt a bejegyzést menetes nézetben
Re: pfctl -ef minden újraindítás után
Válasz erre a hozzászólásra draft-3-mal
>
> # ls -l /etc/pf.conf
> -rw ------- 1 gyökér kerék 1989 szept. 30 23:29 /etc/pf.conf
>
> # cat /etc/rc.conf | grep pf
> ospfd_flags = NO # normál használat esetén: ""
> ospf6d_flags = NO # normál használat esetén: ""
> pf = NO # Csomagszűrő / NAT
^^ YES-nek kell lennie
> pf_rules = / etc / pf.conf # Csomagszűrő szabályfájl
> pflogd_flags = # további zászlók hozzáadása, pl. "-s 256"
>
> # cat /etc/rc.conf.local | grep pf
> pf = IGEN
rc.conf.local egy másik szolgáltatáshoz
>
--
Dinar Talipov
Nyissa meg ezt a bejegyzést menetes nézetben
Re: pfctl -ef minden újraindítás után
>> # ls -l /etc/pf.conf
>> -rw ------- 1 gyökér kerék 1989 szept. 30 23:29 /etc/pf.conf
>> # cat /etc/rc.conf | grep pf
>> ospfd_flags = NO # normál használat esetén: ""
>> ospf6d_flags = NO # normál használat esetén: ""
>> pf = NO # Csomagszűrő / NAT
> ^ ^ YES-nek kell lennie
>> pf_rules = / etc / pf.conf # Csomagszűrő szabályfájl
>> pflogd_flags = # add több zászlót, pl. "-s 256"
>> # cat /etc/rc.conf.local | grep pf
>> pf = IGEN
> és rc.conf.local egy másik szolgáltatáshoz
Igen, igen?
és mi, akkor?
Már rohadt vagyok - mennyi időt töltöttem az rc.conf-ben, és csak az én
koncentrátum eldobott az rc.conf.local-ban
a legszórakoztatóbb az, hogy a helyváltoztatás helyét a diszlokáció pf = YES eredmény
a mi esetünkben a nikróm nem fog változni.
Nyissa meg ezt a bejegyzést menetes nézetben
Re: pfctl -ef minden újraindítás után
Válasz erre Dinar Talypov erre a hozzászólásra
Dinar Talypov írja:
^^^ nem, mert Az rc.conf nem szerkeszthető.
>> pf_rules = / etc / pf.conf # Csomagszűrő szabályfájl
>> pflogd_flags = # add több zászlót, pl. "-s 256"
>>
>> # cat /etc/rc.conf.local | grep pf
>> pf = IGEN
>>
> és rc.conf.local egy másik szolgáltatáshoz
>
Minden rc.conf.local helyesen van leírva.
Látom a pf.conf szabályok egy sorát?
Nyissa meg ezt a bejegyzést menetes nézetben
Re: pfctl -ef minden újraindítás után
Válasz erre a hozzászólásra draft-3-mal
Azt hiszem, a Dinara összezavarhatja az ember következő rc.conf sorát:
Az /etc/rc.conf fájlt nem szabad érintetlenül hagyni
hozhat létre és szerkeszthet egy új /etc/rc.conf.local fájlt. Ebben a változókban
fájl felülírja a /etc/rc.conf fájlban korábban megadott változókat.
itt csak "ebben a változókban" vannak, amint azt a gyakorlat mutatja, nem
azt jelenti, hogy csak a változók kerülhetnek a helyi -
Logikai EU / NU is. a CD-n. legalábbis nem szenvedett ettől
Az rc.conf.local YES / NO parancsot tartalmazom
Igor Grabin írta:
Nyissa meg ezt a bejegyzést menetes nézetben
Re: pfctl -ef minden újraindítás után
Válasz erre a hozzászólásra draft-3-mal
Igor Grabin írta:
Igen, minden jó lenne. csak a kiszolgáló a konzol nélkül: - [
> vagy, gondosan olvassa el újra, a dns nevek témájára (akkoriban)
> kezdjük, amikor a pfctl szinte mindig megnevezett még nem szinkronizált)
> tun'ov (ami még mindig hülye a pfctl pillanatában) és így tovább.
>
ez szinte a lényeg.
A szabályokban mind az alagút, mind a továbbító anyagok megjelennek, és
domainnevek, így szinte biztos, hogy
a probléma az, hogy az internetet még nem emelték fel (az alagúton keresztül - adless)
köszönöm a csúcsot!
> lehetséges megoldások:
>
a másik oldalról jönnek. hogyan lehet megoldani a problémát?
nem elegáns lehetőségek sok - beleértve, hogy elkezd pf után
Ineta emelés. ("pf = NO" + "pfctl-e"), de ez így van. biztosan nem
igaza van
opcióként elvetheti a szabályok dns nevét, miközben megsemmisít
pfctl, mert képtelen megoldani őket, de viszont létrehoz
egyéb kellemetlenségek. és akkor a tun-a a szabályokban biztosan nem
visszautasítani.
(ami szintén sokkal később nő).
> pfctl -ef a tail rc.local-ban. nem elegendő.
> füst pf.conf előtt megvilágosodás, miért nem duplex pfctl rendszer
>
Pontosan tudtam, hogy a pfctl nem annyira fogadja el a szabályokat
mert
ami nem mondhatja el, hogy megoldja a nevét, hanem azért, mert erre
a hely megbotlik
a szintaxisban keletkező hibára.
> kiszámíthatja, hogy vannak szintaktikai hibák
Nyissa meg ezt a bejegyzést menetes nézetben
Re: pfctl -ef minden újraindítás után
téma a dns nevekkel Általában razrulival írni szabályokat
asztalok, és maguk a táblázatok kitöltése - már külön script, majd.
> Jól tudtam, hogy a pfctl nem annyira fogadja el a szabályokat
mert,
> amely nem mondhatja el, hogy megoldja a nevet, hanem azért, mert erre
> a hely megbotlik
> a szintaxisban keletkező hibára.
yyy. az egyik mereven követi a másikat. vagy van egy kreativitás,
Hogyan lehet ezeket az eseményeket eltávolítani egymástól? -)
Nyissa meg ezt a bejegyzést menetes nézetben
Re: pfctl -ef minden újraindítás után
Igor Grabin írta:
mmm, itt is iptables, mint általában, nevek, amelyekben nem
Megoldás, csak hiányzik. pf, amennyire én emlékszem, amikor hivatkoztam
kézzel is valahogy a szintaxis nem panaszkodott, ha nem talál valamit.
valami csak kihagyta a szabályt.
Talán nem találkoztam egyszerűen.
általában minden világos. Köszönjük, hogy részt vettél.
Nyissa meg ezt a bejegyzést menetes nézetben
Re: pfctl -ef minden újraindítás után
Válasz erre a hozzászólásra draft-3-mal
1. a -e, miért.
Ha rc.conf * kiderül pf = YES, akkor PF és így kell zanenblen.
Ha a letöltés után nem engedélyezett, akkor az / etc / rc *
ami megölt (pl. rc.conf.local in
/etc/rc.conf állományban)
2. Mutassa be a pfctl -sr parancsot a letöltés időpontjában, ha üres, ez
egy másik fad az 1. bekezdés mellett.
Ha a pf.conf hiba történt, az eszközt be kell tölteni
csak az ssh és néhány apróság.
4. Biztos benne, hogy az / etc / rc dolgozott. Valamit elkaptam
programok az előtérben (a "" nélkül) rc.local-ban. Az igazság az
(vagy inkább az elméjük testvére), végül nem futott be cron.
Más szóval - hibakeresés és nyomkövetési indító szkriptek, a probléma
valahol belőlük, vagy végrehajtásuk idején.
Nyissa meg ezt a bejegyzést menetes nézetben
Re: pfctl -ef minden újraindítás után
Válasz erre a hozzászólásra draft-3-mal
Soha nem használok nevet a PF DNS-ben. Mindig fennáll annak a veszélye, hogy valami nem
még akkor is, ha a DNS elérhető. Macro-t csinálok
host_domain_com = "IP" és használja őket a szabályokban. Egyetértek azzal, hogy nem megfelelő,
de megbízhatóan.
Van egy ötlet, hogy készítsen egy konfigurációs fájlt, amely megoldódik
neveket és helyezze be az IP-t. Itt van egy feldolgozott konfiguráció
elterjedt az /etc/pf.conf fájlban. Számomra kényelmes, hiszen a konfigurációk eltérőek
tűzfalak Még mindig mak'omot generálok és az eredeti sablonokat cvs-ben tárolom.
Az ilyen irányító nem nehéz, de talán valaki már megmondja
kész segédprogram.
Nyissa meg ezt a bejegyzést menetes nézetben
Re: pfctl -ef minden újraindítás után
Válasz erre a hozzászólásra draft-3-mal
utolsó sor az rc.localban
pfctl -f /etc/conf/pf.conf> /var/log/pf.start.log 2> 1
>> vagy, gondosan olvassa el újra, és nézze meg a dns nevek témáját (abban az időben
>> akkor kezdődhet, amikor a pfctl szinte mindig elnevezett még nem lett átnevezve)
>> tun'ov (ami még mindig hülye a pfctl pillanatában) és így tovább.
>>
Ez majdnem a lényeg.
> a szabályokban van egy alagút, valamint egy továbbító, és
> domainnevek, így szinte biztos, hogy
> a probléma az, hogy az internetet még nem emelték fel (az alagúton keresztül - adless)
>
> köszönöm a tippet!
>> lehetséges megoldások:
>>
> a másik oldalról jönnek. hogyan lehet megoldani a problémát?
> nem sok elegáns lehetőség van - beleértve, hogy elkezdjük a pf-et
> Ineta emelés. ("pf = NO" + "pfctl-e"), de ez így van. biztosan nem
> igaza van
>
> opcióként dobja el a szabályok dns-nevét, miközben nem fog összeomlani
> pfctl, mert nem lehet megoldani őket, viszont ez megteremti
> egyéb kényelmetlenség. és akkor a tun-a a szabályokban biztosan nem
> megtagadni.
> (ami szintén sokkal később emelkedik).
>> pfctl -ef az rc.local végén. nem elegendő.
>> a pf.conf előtt füstölni a megvilágosodás előtt, miért nem duplex pfctl rendszeren
>>
> Jól tudtam, hogy a pfctl nem annyira fogadja el a szabályokat
mert,
> amely nem mondhatja el, hogy megoldja a nevet, hanem azért, mert erre
> a hely megbotlik
> a szintaxisban keletkező hibára.
--
Üdvözlettel: Lyubimets Andrey Alekseevich
Nyissa meg ezt a bejegyzést menetes nézetben
Re: pfctl -ef minden újraindítás után
Andrey Lyubimets írta:
Nos, akkor ne rc.local. és valahol cat / etc / rc | grep -n pfctl
de az rc.local miatt valószínűleg jól fog működni.
Nyissa meg ezt a bejegyzést menetes nézetben
Re: pfctl -ef minden újraindítás után
Nem gyakoroltam, így kaptam meg
--
Üdvözlettel: Lyubimets Andrey Alekseevich