Re: OpenVPN, IPFW a NAT
Ciernik Tomas napsal(a): Zbyněk Burget wrote / napísal(a): Ciernik Tomas napsal(a): 02010 skipto 65010 tcp from any to any out via tun3 setup keep-state 02011 skipto 65010 ip from any to any out via tun3 keep-state ^^^ ^^ nejsem si jist tim, ze zrovna tohle bude fungovat - nevim, jestli se pri naslednem check-state provede ten skok Bol som v domneni, ze ten check-state nic neurobi - ziadne spojenie este nebolo nadviazane, takze by mal ist dalej na skipto. keep-state vyrobi dynamicke pravidlo pro tok, jehoz packet pravidlo zpracovalo. Check-state pak zkontroluje, zda pro packet existuje takto vyrobene dynamicke pravidlo a pokud ano, preda jej tomu dynamickemu pravidlu. A ja si nejsem jisty tim, zda jako dynamicke pravidlo pujde vytvorit skipto... ...pripadne se vybodnout na stavovy firewall a pouzit firewall nestavovy. Mimochodem - mas nejaky vazny duvod k pouziti stavoveho firewallu? Ako sa pozeram na logy ani nie, kazdopadne si myslim ze je lepsie povolit len riadne nadviazane spojenia. Toto lze pro TCP spojeni resit i jenak, nez stavovym firewallem - podivej se na volbu "established". Pro UDP samozrejme rozhodovani stavovy / nestavovy firewall nema smysl... Zbynek -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: core dump
va...@kcorp.sk napsal(a): nemuze to byt kombinace amd64 a jail? Ony se v jailech obcas najdou chybky i v i386. Amd64 je prece jen novejsi, nevychytanejsi. Ono moze byt to aj tym ale zatial som z AMD64 ako takou nemal problem (co ale nevylucuje) , mam ju nasadenu na desiatkach serverov, rozne nasadenia a spominany 1 server je tiez z 3 jailami bezi 5 mesiacov bez chyb z 200 maildomenami a cca tolko aj DNS domen a celkom je tam frmol. Ja tady nemyslel, ze by to muselo nutne vsude bezne coredumpovat - muze to byt chybkou, ktera se projevi jen v nejake urcite konktretni situaci. Jak jsem psal - v pripade jailu se muze chyba objevit i na i386, tim spis na amd64 Zbynek -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: core dump
va...@kcorp.sk wrote: Panic String: ufs_dirbad: /jail_Development: bad dir ino 3963266 at offset 1849344: mangled entry Moznosti jsou dve - bud' je skutecne poskozeny filesystem. Pak bych zkusil: a) fsck (v single rezimu) b) smazat a (z neceho) obnovit celu obsah /jail_Development c) kompletne preformatovat a za zalohy obnovit obsah poskozeneho svazku Jestli jsou ty dva servery opravdu totozne, nemelo by byt kompletni obnoveni problem - proste se to zcela nakopiruje "od vedle". Ja jen (protoze nevim, komu radim) podotknu, ze prekopirovani svazku/obnoveni ze zalohu (obdobne pro adresar) - tim nemyslim "cp -r" a i s TARem je treba byt peclivy a opatrny. Primarni tool pro tento problem je dump/restore. Nezodpovezenou otazkou zustava, jak k poskozeni filesystemu doslo - a tudiz - jak casto k nemu bude dochazet v budoucnosti. Druba moznost je, ze filesystem na disku poskozeny neni. Pak to muze byt vada ovladacu (zejmena pripomenme, ze jsme na AMD64 architekture), vada radice, pameti, kolize na sbernicich (preruseni) a dalsi podobne veci. Ale to se zjisti snadno - proste ty disky mezi servery prehod. Pokud zavada zustane, tak s disky nesouvisi a muzes pokracovat prehazovanim dalsich komponent. Az se prestehuje - mas vadnou komponentu. Dan -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Problem s OpenVPN
Milan Cizek wrote: Ping (z pohledu klienta neuspesny) z klienta na zarizeni v LAN (em0 je LAN sitovka 192.168.1.1)... server# tcpdump -vvv -i em0 icmp tcpdump: listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes 23:49:32.539675 IP (tos 0x0, ttl 127, id 52368, offset 0, flags [none], proto ICMP (1), length 60) 172.20.0.6 > 192.168.1.2: ICMP echo request, id 768, seq 57603, length 40 No, ted je proste treba jit "po ceste" a v jednotlivych bodech si taky udelat dump (vzdy zvlast na prichozim a odchozim interface). A jak tak budes postupovat, moznosti jsou dve - - ztrati se ti "dopredny paket" (nezachytis nic) - to ti ho bud' prave sezral firewall nebo vadny routing poslal nekam jinam. - nebo nahle zacnes zachytavat krome doprednych paketu i zpetne - a to znamena, ze firewall likviduje jen ten opacny smer, nebo routing smeruje pakety blbe prave v opacnem smeru. Jakmile budes vedet, kde presne se ktery smer ztraci, bude ta uloha podstatne jednodussi ... Dan -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Problem s OpenVPN
Milan Cizek napsal(a): Ahoj, Takovy hloupy postreh, mas tam icmp echo request ale nevidim reply, ten dump by mel ukazovat i to :) nemas tam naproti nahodou wokna s defaultnim firewallem ? v tom pripade ti totiz vpn funguje jak ma ale nevodpovidaj ti ty wokna :-D proto jsem prilozil ten uspesny ping primo ze serveru na dalsim radku. ;-) Tahle konkretni IP neni ani PC ale nejaky managed switch, nicmene i na PC se to chova naprosto stejne. Jeste muze jit o to, kterou adresu server pouzije pri tom pingu. Z toho dumpu je videt, ze pri neuspesnem pokusu se pouzije spojovacka (172.20.0.6). Ale v pripade pingu ze serveru uz patrne pouzije 192.168.1.1. Windowsi firewall, sit 172 patrne zarizne, protoze jeho mistni sit ma 192.168. Zkus jeste ze serveru ping -S 172.. 192.168.1.x. (ted nevim, jakou 172.x.y.z) mas na serveru pouzitelnou. PM -- # --- # Petr Macek # p...@kostax.cz # icq: 87323239 # www.kostax.cz -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Problem s OpenVPN
Predpokladam, ze je to smerovaci tabulka na serveru, kde je i spustena OpenVPN. Moznaje to tim, ze je brzo rano, ale nevidim zde pravidlo pro sit 102.168.2.0/24 na kterou se snazis pingnout ze site 192.168.1.0/24. Abych byl konkretni, tak se mi zda, ze tu chybi server# route add 192.168.2.0/24 172.20.0.6 (tu sestku na konci jsem si vymyslel, ma to byt adresa iface na serveru te vpnky) Michal Milan Cizek napsal(a): > > Aktivní směrování: >Cíl v síti Síťová maskaBránaRozhraní Metrika > 0.0.0.0 0.0.0.0 10.0.3.1 10.0.3.20 20 > 10.0.3.0255.255.255.010.0.3.20 10.0.3.20 20 > 10.0.3.20 255.255.255.255127.0.0.1 127.0.0.1 20 >10.255.255.255 255.255.255.25510.0.3.20 10.0.3.20 20 > 127.0.0.0255.0.0.0127.0.0.1 127.0.0.1 1 >172.20.0.0255.255.255.0 172.20.0.5 172.20.0.6 1 >172.20.0.4 255.255.255.252 172.20.0.6 172.20.0.6 30 >172.20.0.6 255.255.255.255127.0.0.1 127.0.0.1 30 >172.20.255.255 255.255.255.255 172.20.0.6 172.20.0.6 30 > 192.168.1.0255.255.255.0 172.20.0.5 172.20.0.6 1 > 224.0.0.0240.0.0.010.0.3.20 10.0.3.20 20 > 224.0.0.0240.0.0.0 172.20.0.6 172.20.0.6 30 > 255.255.255.255 255.255.255.25510.0.3.20 10.0.3.20 1 > 255.255.255.255 255.255.255.255 172.20.0.6 172.20.0.6 1 > Výchozí brána: 10.0.3.1 > > Milan > -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
