abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 10:00 | IT novinky

Po open source ergonomickému trackballu (dnes Classic Trackball) a open source myši představila společnost Ploopy nový open source Nano Trackball (GitHub). Trackball bez tlačítek a kolečka. Pouze kulička.

Ladislav Hagara | Komentářů: 0
dnes 09:00 | Bezpečnostní upozornění

Webový prohlížeč Brave lze vedle standardního prohlížení (Nové okno) a anonymního prohlížení (Nové soukromé okno) používat i pro anonymní prohlížení s využitím Toru (Nové soukromé okno přes Tor) a pro přistup k webům v doméně .onion. Nejnovější verze Brave řeší několik bezpečnostních chyb, kdy DNS dotazy místo do Toru směrovaly k poskytovateli DNS. Ten tak mohl zjistit, že uživatel chtěl přistupovat například k sejnfjrq6szgca7v.onion (debian.org).

Ladislav Hagara | Komentářů: 0
dnes 08:00 | Nová verze

Byla vydána nová verze 2021.1 průběžně aktualizované linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek i s náhledy a seznamem nových nástrojů v oficiálním oznámení. Kali Linux má nové webové stránky.

Ladislav Hagara | Komentářů: 0
včera 17:22 | Nová verze

Multiplatformní open source počítačová hra Minetest byla vydána ve verzi 5.4.0. Přehled změn v changelogu. Jedná se o hru inspirovanou Minecraftem.

Ladislav Hagara | Komentářů: 1
včera 09:00 | Nová verze

Byla vydána (Twitter) nová verze 3.18 svobodného multiplatformního geografického informačního systému QGIS (Wikipedie). Přehled novinek i s náhledy a animovanými gify ve visuálním changelogu a také na YouTube.

Ladislav Hagara | Komentářů: 0
včera 08:00 | Nová verze

Byla vydána nová verze 4.16 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl aktualizován na verzi 10.0.12. Thunderbird byl aktualizován na verzi 78.7.0. Linux byl aktualizován na verzi 5.10.13. Tor byl aktualizován na verzi 0.4.5.5.

Ladislav Hagara | Komentářů: 0
včera 07:00 | Nová verze

Dokumentační tým projektu LibreOffice vydává příručku Getting Started Guide 7.0. Příručka je určena pro každého, kdo se chce seznámit s programem LibreOffice a představuje hlavní komponenty LibreOffice: textový procesor Writer, tabulkový procesor Calc, prezentační program Impress, vektorový grafický program Draw, databázový program Base a editor rovnic Math. Příručka je ke stažení na stránce LibreOffice, kde lze stáhnout i české překlady dalších příruček.

Zdeněk Crhonek | Komentářů: 3
23.2. 15:55 | Nová verze

Byl vydán Mozilla Firefox 86.0. Přehled novinek v poznámkách k vydání, poznámkách k vydání pro firmy a na stránce věnované vývojářům. Novinkou je Total Cookie Protection aneb "každý web má vlastní dózu na sušenky". Nově lze používat funkci obraz v obraze současně pro několik videí. Řešeny jsou také bezpečnostní chyby. Nejnovější Firefox je již k dispozici také na Flathubu.

Ladislav Hagara | Komentářů: 13
23.2. 15:22 | Zajímavý článek

Unix na jednočipovém počítači Raspberry Pi Pico? Příspěvek na blogu Raspberry Pi ukazuje, jak na něm rozchodit Fuzix OS (GitHub). Alan Cox představil (png) Fuzix OS v říjnu 2014 jako Unix pro osmibitový mikroprocesor Zilog Z80.

Ladislav Hagara | Komentářů: 3
23.2. 09:00 | Nová verze

Byla vydána nová stabilní verze 21 open source cloudového systému Nextcloud (Wikipedie). Dle oznámení může být nejnovější verze tohoto forku ownCloudu až 10krát výkonnější než předchozí verze. Podrobnosti i s náhledy a videi v příspěvku na blogu. Vyzkoušet lze online demo.

Ladislav Hagara | Komentářů: 3
Co používáte k zaznamenávání úkolů či poznámek?
 (36%)
 (16%)
 (34%)
 (9%)
 (22%)
 (21%)
 (21%)
Celkem 326 hlasů
 Komentářů: 14, poslední 19.2. 10:41
Rozcestník

Dotaz: ipsec site-to-site tunel pinga jen z jedne strany

7.12.2017 21:48 y.
ipsec site-to-site tunel pinga jen z jedne strany
Přečteno: 404×
Potreboval bych poradit jak tohle resit. Mam rozbehanout ipsec VPN (site-to-site). Na jednom konci je Ubiquiti Edge Max router (hostname ubnt) a na iface ma verejnou adresu. Neprekvapim, pokud konstatuji, ze uvnitr mam nat. Na druhem konci je Turris Omnia (hostname turris) a na outgoing iface ma soukromou adresu poskytovatele. Nicmene od poskytovatele mam prirazenou i verejnou adresu a router naprosto bez problemu reaguje i pres tu verejnou adresu. Jak je to technologicky reseno nevim, ale chova se to proste jako kdyby byly vsechny porty z verejne adresy smerovany na muj externi iface. Za tim iface take jedu NAT, cili je to externi-IP -> interni IP poskytovatele (10.x) -> interni sit moje (192.168.252.0.24). Jelikoz jsou ty routery napric kontinenty a jelikoz potrebuju obcas neco opravit na jedne ci druhe strane, chtel jsem obe site propojit pres IPSec. Ty interni site nekoliduji, to uz jsem si zmenil. Po dvou dnech prerusovaneho snazeni jsem v situaci, z ubnt pingnu vnitrni adresy site za turris, ale obracene to nejde. Jeste je to bohuzel zkomplikovane (aspon pro moje chapani situace) tim, ze zatimco na ubnt je to reseny pres policies (?) a tedy nevidim zadny interface, na turrisu mi strongswan pri startu vytvori ipsec0 interface. Ocividne nejaky traffic pres ten interface projde, ale jen jednim smere... Kdyz jsem totiz na turris a na pozadi zavolam ping 192.168.250.1 (na pozadi) a koukam na interfacy, vidim nasledujici:
root@turris:~# tcpdump -i ipsec0  -n icmp or udp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ipsec0, link-type RAW (Raw IP), capture size 262144 bytes
21:18:00.694485 IP 10.77.154.193 > 192.168.250.1: ICMP echo request, id 41260, seq 0, length 64
21:18:01.695720 IP 10.77.154.193 > 192.168.250.1: ICMP echo request, id 41260, seq 1, length 64
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel
root@turris:~# tcpdump -i eth1  -n icmp or udp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
//provoz, ale nevidim nic co by se vztahovalo k memu pingu
//i.e. nic jako UDP-encap: ESP(spi=0xc7fd7ae3,seq=0x70), length 132
root@turris:~# tcpdump -i ipsec0  -n icmp or udp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ipsec0, link-type RAW (Raw IP), capture size 262144 bytes
21:18:52.704185 IP 10.77.154.193 > 192.168.250.1: ICMP echo request, id 41260, seq 52, length 64
21:18:53.705168 IP 10.77.154.193 > 192.168.250.1: ICMP echo request, id 41260, seq 53, length 64
21:18:54.706153 IP 10.77.154.193 > 192.168.250.1: ICMP echo request, id 41260, seq 54, length 64
^C
3 packets captured
3 packets received by filter
0 packets dropped by kernel
Takze zatim to vypada, ze se po vstupu na ipsec0 packety nekam ztrati. Hadam tedy budto neco v iptables a nebo jeste nekde je neco spatne, ale nevim, na co koukat. Mate nekdo nejaky napad

Na turris:
root@turris:~# ipsec statusall
no files found matching '/etc/strongswan.d/*.conf'
Status of IKE charon daemon (strongSwan 5.3.5, Linux 4.4.91-e8cacce0ae0bf48eea19d58c2e860359-1, armv7l):
  uptime: 59 minutes, since Dec 07 20:40:42 2017
  worker threads: 6 of 16 idle, 6/0/4/0 working, job queue: 0/0/0/0, scheduled: 5
  loaded plugins: charon test-vectors ldap pkcs11 aes des blowfish rc2 sha1 sha2 md4 md5 random nonce x509 
  revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl gcrypt af-alg fips-prf 
  gmp agent xcbc cmac hmac ctr ccm gcm curl mysql sqlite attr kernel-libipsec kernel-netlink resolve socket-default
  connmark farp stroke smp updown eap-identity eap-md5 eap-mschapv2 eap-radius eap-tls xauth-generic xauth-eap 
  dhcp whitelist led duplicheck addrblock unity
Listening IP addresses:
  10.77.154.193
  192.168.254.2
  192.168.252.1
  fda0:2209:2f01::1
  192.168.253.1
Connections:
peer-XXX.xxxree.net-tunnel-1:  XXX.xxxree.net,0.0.0.0/0,::/0...yyy.ddns.net,0.0.0.0/0,::/0  IKEv1
peer-XXX.xxxree.net-tunnel-1:   local:  [XXX.xxxree.net] uses pre-shared key authentication
peer-XXX.xxxree.net-tunnel-1:   remote: uses pre-shared key authentication
peer-XXX.xxxree.net-tunnel-1:   child:  192.168.252.0/24 === 192.168.250.0/24 TUNNEL
Routed Connections:
peer-XXX.xxxree.net-tunnel-1{1}:  ROUTED, TUNNEL, reqid 1
peer-XXX.xxxree.net-tunnel-1{1}:   192.168.252.0/24 === 192.168.250.0/24
Security Associations (1 up, 0 connecting):
peer-XXX.xxxree.net-tunnel-1[1]: ESTABLISHED 33 minutes ago, 10.77.154.193[XXX.xxxree.net]...y.y.y.y[y.y.y.y]
peer-XXX.xxxree.net-tunnel-1[1]: IKEv1 SPIs: 3650f1ed90c3ebbe_i 74679c88fb4978f3_r*, pre-shared key reauthentication in 7 hours
peer-XXX.xxxree.net-tunnel-1[1]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
peer-XXX.xxxree.net-tunnel-1{2}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: e86905ed_i c7fd7ae3_o
peer-XXX.xxxree.net-tunnel-1{2}:  AES_CBC_256/HMAC_SHA1_96, 9408 bytes_i (112 pkts, 293s ago), 9408 bytes_o (112 pkts, 293s ago), rekeying in 11 minutes
peer-XXX.xxxree.net-tunnel-1{2}:   192.168.252.0/24 === 192.168.250.0/24

Odpovědi

7.12.2017 22:37 NN
Rozbalit Rozbalit vše Re: ipsec site-to-site tunel pinga jen z jedne strany
21:18:52.704185 IP 10.77.154.193 > 192.168.250.1: ICMP echo request, id 41260, seq 52, length 64
21:18:53.705168 IP 10.77.154.193 > 192.168.250.1: ICMP echo request, id 41260, seq 53, length 64
Nemelo by to nahodou do tulenu chodit ciste = nepremaskovane na 10.77.154.193? Nemas tam nahodou maskaradu na vsechno co jde ven?
8.12.2017 03:15 y.
Rozbalit Rozbalit vše Re: ipsec site-to-site tunel pinga jen z jedne strany
To bylo ono!
root@turris:~# ping 192.168.250.1
PING 192.168.250.1 (192.168.250.1): 56 data bytes
64 bytes from 192.168.250.1: seq=0 ttl=64 time=109.060 ms
64 bytes from 192.168.250.1: seq=1 ttl=64 time=108.753 ms
64 bytes from 192.168.250.1: seq=2 ttl=64 time=109.128 ms
64 bytes from 192.168.250.1: seq=3 ttl=64 time=108.984 ms
Super, diky moc za nakopnuti Este pro uplnost (snad to nekomu pripadne pomuze)
root@turris:~# tcpdump -i ipsec0  -n icmp or udp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ipsec0, link-type RAW (Raw IP), capture size 262144 bytes
03:09:03.749067 IP 192.168.252.1 > 192.168.250.1: ICMP echo request, id 35358, seq 24, length 64
03:09:03.855987 IP 192.168.250.1 > 192.168.252.1: ICMP echo reply, id 35358, seq 24, length 64
03:09:04.750038 IP 192.168.252.1 > 192.168.250.1: ICMP echo request, id 35358, seq 25, length 64
03:09:04.858260 IP 192.168.250.1 > 192.168.252.1: ICMP echo reply, id 35358, seq 25, length 64
a tohle je vypis z eth1 (moje egress iface)
03:08:39.743681 IP 10.77.154.193.4500 > ext-ip-UBNT.4500: UDP-encap: ESP(spi=0xca7b4555,seq=0x5), length 132
03:08:39.850349 IP ext-ip-UBNT.4500 > 10.77.154.193.4500: UDP-encap: ESP(spi=0xb97a7b4f,seq=0x5), length 132
03:08:40.744794 IP 10.77.154.193.4500 > ext-ip-UBNT.4500: UDP-encap: ESP(spi=0xca7b4555,seq=0x6), length 132
03:08:40.852074 IP ext-ip-UBNT.4500 > 10.77.154.193.4500: UDP-encap: ESP(spi=0xb97a7b4f,seq=0x6), length 132
03:08:41.745913 IP 10.77.154.193.4500 > ext-ip-UBNT.4500: UDP-encap: ESP(spi=0xca7b4555,seq=0x7), length 132
kde 10.77.154.193 je egress IP stroje turris (jak jsem rikal, nema verejnou adresu, ale asi nejakou verzi 1:1 NAT nebo neceho takove). Jeste jednou diky!
8.12.2017 03:24 y.
Rozbalit Rozbalit vše Re: ipsec site-to-site tunel pinga jen z jedne strany
Příloha:
Jeste prikladam obrazek nastaveni. Tu guest zonu a vpn_turris zonu jsem nepridal ja -- jedno je openVPN pristup pres Omnia wizarda a to druhy je guest network od jejich jineho wizarda. Zda se mi, ze vse funguje tak jak ma, ale ocenim pripadnou kontrolu -- kdyis jsem si s tim v zoufalosti hral a mozna jsem neco zkonil. Pokud je to ok, tak tu aspon zustane reference na to, jak to ma nastavene vypadat.

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.