openbsd 4.5 cu toate patch-urile de la errata
Problema: după fiecare repornire trebuie să vă lipiți manual
pe ssh și chop pfctl -ef /etc/pf.conf, altfel NAT nu funcționează,
iar pachetele între interfețe nu sunt rutate.
Nimeni nu sa confruntat cu asta? Prin setări, totul este clarificat
cum ar fi. Și în sine funcționează așa cum ar trebui
(NAT / rutare și TP). Deja, cel puțin, pf trebuie să înceapă,
iar drepturile la pf.conf sunt corecte și nu există erori în config. am citit
undeva, că reconstruirea kernel-ului cu ipv6 dezactivarea accidentelor pf,
dar acest lucru nu este cazul meu (nu am contactat ipv6). Detaliile sunt de mai jos. Mulțumesc.
# diff ./GENERIC ./MYCONF
13c13
> include "../../../conf/MYCONF"
34c34
<#option NTFS # Experimental NTFS support
---
> opțiune NTFS # Suport NTFS experimental
# diff. /../../conf/GENERIC. /../../conf/MYCONF; echo $?
0
# ls -l /etc/pf.conf
-rw ------- 1 roată rotativă 1989 Sep 30 23:29 /etc/pf.conf
# cat /etc/rc.conf | grep pf
ospfd_flags = NO # pentru utilizare normală: ""
ospf6d_flags = NO # pentru utilizare normală: ""
pf = NO # Filtru de pachete / NAT
pf_rules = / etc / pf.conf # Fișier de reguli pentru pachetele de pachete
pflogd_flags = # adăugați mai multe steaguri, adică. "- 256"
# cat /etc/rc.conf.local | grep pf
pf = DA
# pfctl -nf /etc/pf.conf; echo $?
0
după pornirea manuală pfctl -ef /etc/pf.conf funcționează totul.
Nu faceți clic cu ciocul dvs. la boot time și a vedea de ce pfctl
a refuzat să pătrundă pf.conf în acel moment.
fie, re-citit-o gandit, uita-te la subiectul dns nume (la momentul
începe de la momentul pfctl aproape întotdeauna numit nu a fost încă numit), everyones
tun'ov (care este încă prost în momentul de față pfctl) și așa mai departe.
pfctl -ef în coada rc.local. este inelegant.
fum pf.conf înainte de iluminare, de ce pe un sistem non-duplex pfctl
poate calcula că există erori de sintaxă
Deschideți această postare în vizualizare cu filet
Re: pfctl -ef după fiecare repornire
Ca răspuns la acest mesaj de proiectul 3
>
> # ls -l /etc/pf.conf
> -rw ------- 1 roată roată 1989 Sep 30 23:29 /etc/pf.conf
>
> # cat /etc/rc.conf | grep pf
> ospfd_flags = NO # pentru utilizare normală: ""
> ospf6d_flags = NO # pentru utilizare normală: ""
> pf = NO # Filtru de pachete / NAT
^ ^ trebuie să fie DA
> pf_rules = / etc / pf.conf # Fișier de reguli pentru pachetele de pachete
> pflogd_flags = # adăugați mai multe drapele, adică. "- 256"
>
> # cat /etc/rc.conf.local | grep pf
> pf = DA
rc.conf.local pentru altul servește
>
--
Dinar Talipov
Deschideți această postare în vizualizare cu filet
Re: pfctl -ef după fiecare repornire
>> # ls -l /etc/pf.conf
>> -rw ------- 1 roată rădăcină 1989 Sep 30 23:29 /etc/pf.conf
>> # cat /etc/rc.conf | grep pf
>> ospfd_flags = NO # pentru utilizare normală: ""
>> ospf6d_flags = NO # pentru utilizare normală: ""
>> pf = NO # Filtru de pachete / NAT
> ^^ trebuie să existe DA
>> pf_rules = / etc / pf.conf # Fișier de reguli pentru pachetele de pachete
>> pflogd_flags = # adăugați mai multe steaguri, adică. "- 256"
>> # cat /etc/rc.conf.local | grep pf
>> pf = DA
> și rc.conf.local pentru altul
Da, bine?
și pentru ce, atunci?
Sunt deja naibii - cât de mult timp în rc.conf mă uit doar, și toate mele
concentrat aruncat în rc.conf.local
cea mai distractiva este cea din schimbarea locatiei rezultatului dislocatiei pf = YES
în cazul nostru, nichromul nu se va schimba.
Deschideți această postare în vizualizare cu filet
Re: pfctl -ef dupa fiecare repornire
Ca răspuns la acest post de Dinar Talypov
Dinar Talypov scrie:
^^^ nu ar trebui, pentru că rc.conf nu poate fi editabil.
>> pf_rules = / etc / pf.conf # Fișier de reguli pentru pachetele de pachete
>> pflogd_flags = # adăugați mai multe steaguri, adică. "- 256"
>>
>> # pisică /etc/rc.conf.local | grep pf
>> pf = DA
>>
> și rc.conf.local pentru altul
>
Totul este corect redat în rc.conf.local.
Pot vedea un set de reguli pf.conf?
Deschideți această postare în vizualizare cu filet
Re: pfctl -ef dupa fiecare repornire
Ca răspuns la acest mesaj de proiectul 3
Cred că Dinara ar putea confunda următoarele rânduri de om rc.conf:
Este recomandabil să lași fișierul /etc/rc.conf neatins, și în schimb
creați și editați un nou fișier /etc/rc.conf.local. Variabilele stabilite în acest
fișierul va suprascrie variabilele setate anterior în /etc/rc.conf.
aici doar "variabile stabilite în acest.", după cum arată practica, nu
înseamnă că numai variabilele pot fi introduse în localitate -
Boolean UE / NU de asemenea. pe CD. cel puțin, nu a suferit de faptul că
Am inclus prin rc.conf.local DA / NU
Igor Grabin a scris:
Deschideți această postare în vizualizare cu filet
Re: pfctl -ef după fiecare repornire
Ca răspuns la acest mesaj de proiectul 3
Igor Grabin a scris:
Da, totul ar fi bine. numai serverul fără consola este: - [
> sau, re-citit-o gândire, uita-te la subiectul dns nume (la momentul
> începeți la momentul pfctl aproape întotdeauna numit nu a fost încă numit), orice
> tun'ov (care este încă prost în momentul de față pfctl) și așa mai departe.
>
acest lucru este aproape punctul.
În reguli, atât tunelul, cât și agenții de expediere apar și
nume de domenii, deci este aproape sigur că
problema este că Internetul nu a fost încă ridicat (prin tunel - adless)
multumesc pentru sfat!
> soluții posibile:
>
vin din cealaltă parte. cum de a rezolva problema?
nu opțiuni elegante foarte mult - inclusiv, pentru a începe pf după
Creșterea ineta. ("pf = NO" + "pfctl -e"), dar este așa. cu siguranță nu
are dreptate
ca opțiune, să renunțe la numele DNS în reguli, fără a distruge
pfctl din cauza incapacității de a le rezolva, dar la rândul lor creează
alte inconveniente. și apoi, de la tun-a în regulile nu este cu siguranță
refuza.
(care se ridică, de asemenea, mult mai târziu).
> pfctl -ef în coada rc.local. este inelegant.
> fum pf.conf înainte de iluminare, de ce pe un sistem non-duplex pfctl
>
Am înțeles corect că pfctl nu refuză să accepte reguli atât de mult
deoarece
care nu poate, să spunem, rezolva numele, ci din cauza faptului că în acest sens
locul se împiedică
cu privire la eroarea rezultată din sintaxă.
> poate calcula că există erori de sintaxă
Deschideți această postare în vizualizare cu filet
Re: pfctl -ef după fiecare repornire
subiect cu nume DNS Eu, de obicei, razrulival scriind reguli pe
tabelele și completarea meselor - deja un script separat și apoi.
> Am înțeles corect că pfctl nu refuză să accepte reguli atât de mult
> deoarece,
> că nu poate, să spunem, să rezolve numele, ci din cauza faptului că în acest sens
> locul se împiedică
> la eroarea rezultată din sintaxă.
yyy. unul urmează rigid pe altul. sau există o creativitate,
Cum pot fi dezbinate aceste evenimente. -)
Deschideți această postare în vizualizare cu filet
Re: pfctl -ef după fiecare repornire
Igor Grabin a scris:
mmm, și aici iptables ca de obicei, nume în care nu pot
Resolvnut, doar pierde. pf, în măsura în care îmi amintesc, când mă refer
manual, de asemenea, cumva pe sintaxa nu s-au plâns, dacă nu a putut găsi ceva.
un fel de săritură doar regula.
poate că nu am întâlnit pur și simplu.
în general, totul este clar. Vă mulțumim că ați participat.
Deschideți această postare în vizualizare cu filet
Re: pfctl -ef după fiecare repornire
Ca răspuns la acest mesaj de proiectul 3
1. a -e este motivul pentru care.
Dacă în rc.conf * se pare pf = DA, atunci PF și așa ar trebui să fie zanenblen.
Dacă nu este permis după descărcare, trebuie să înțelegeți cu / etc / rc *
pentru ceea ce a fost ucis (de exemplu, inclusiv rc.conf.local în
/etc/rc.conf)
2. Afișați pfctl -sr la momentul după descărcare, dacă este gol, asta
un alt aspect în favoarea alineatului (1).
Dacă există o eroare în pf.conf, dispozitivul trebuie încărcat
doar ssh și alte câteva lucruri mici.
4. Sunteți sigur că / etc / rc a lucrat. Am prins cumva lansarea
programe în prim-plan (fără "") în rc.local. Adevărul pe care îl am
(sau, mai degrabă, fratele minții), în cele din urmă nu a executat cron.
Cu alte cuvinte - depanarea și urmărirea scripturilor de pornire, problema
undeva în ele sau în momentul implementării lor.
Deschideți această postare în vizualizare cu filet
Re: pfctl -ef dupa fiecare repornire
Ca răspuns la acest mesaj de proiectul 3
Nu folosesc niciodată nume în PF DNS. Există întotdeauna riscul ca ceva să nu fie
chiar dacă DNS este disponibil. Fac macro-uri
host_domain_com = "IP" și folosiți-le în reguli. Sunt de acord că nu este convenabil,
dar în mod fiabil.
Există o idee de a crea un fișier de configurare, care va fi rezolvat
nume și introduceți IP în loc. Aici este deja configurat un proces de procesare
răspândit în /etc/pf.conf. Pentru mine este convenabil, din moment ce config-urile sunt diferite
firewall-uri inca generam mak'om si pastreaza template-urile originale in cvs.
A face un astfel de manipulant nu este dificil, dar poate cineva va va spune deja
gata utilitate.
Deschideți această postare în vizualizare cu filet
Re: pfctl -ef dupa fiecare repornire
Ca răspuns la acest mesaj de proiectul 3
ultima linie în rc.local
pfctl -f /etc/conf/pf.conf> /var/log/pf.start.log 2> 1
>> sau, re-citit-o cu gândire, uitându-se la subiectul dns nume (la acea dată
>> începe la momentul pfctl aproape întotdeauna numit nu a fost încă numit), orice
>> tun'ov (care este încă prost în momentul de față pfctl) și așa mai departe.
>>
> Asta e aproape punctul.
> în reguli, există un tunel, precum și expeditorii și
> nume de domenii, deci este aproape sigur că
> problema este că internetul nu a fost încă ridicat (prin tunel - adless)
>
> multumesc pentru sfat!
>> soluții posibile:
>>
> vin de partea cealaltă. cum de a rezolva problema?
> nu există multe opțiuni elegante - inclusiv, pentru a începe după pf
> Ineta de creștere. ("pf = NO" + "pfctl -e"), dar este așa. cu siguranță nu
> are dreptate
>
> ca opțiune, aruncați denumirile DNS în reguli, în timp ce nu se va prăbuși
> pfctl din cauza imposibilității de a le rezolva, dar la rândul lor creează acest lucru
> alte inconveniente. și apoi, de la tun-a în regulile nu este cu siguranță
> refuzați.
> (care se ridică, de asemenea, mult mai târziu).
>> pfctl -ef la sfârșitul rc.local. este inelegant.
>> pentru a fuma pf.conf înainte de iluminare, de ce pe un sistem non-duplex pfctl
>>
> Am înțeles corect că pfctl nu refuză să accepte reguli atât de mult
> deoarece,
> că nu poate, să spunem, să rezolve numele, ci din cauza faptului că în acest sens
> locul se împiedică
> la eroarea rezultată din sintaxă.
--
Cu sinceritate, Lyubimets Andrey Alekseevich
Deschideți această postare în vizualizare cu filet
Re: pfctl -ef după fiecare repornire
Andrey Lyubimets a scris:
Ei bine, atunci nu în rc.local. și undeva în pisică / etc / rc | grep -n pfctl
dar este din cauza rc.local, probabil că va funcționa bine.
Deschideți această postare în vizualizare cu filet
Re: pfctl -ef după fiecare repornire
Nu am practicat, așa am prins
--
Cu sinceritate, Lyubimets Andrey Alekseevich
Trimiteți-le prietenilor: