OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
Byla vydána nová verze 6.2 ž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 povýšen na verzi 13.0.14.
Byla vydána nová verze 30.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí JavaScriptu, HTML a CSS Electron (Wikipedie, GitHub). Chromium bylo aktualizováno na verzi 124.0.6367.49, V8 na verzi 12.4 a Node.js na verzi 20.11.1. Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.
Byla vydána nová verze 9.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 220 vývojářů. Provedeno bylo více než 2 700 commitů. Přehled úprav a nových vlastností v seznamu změn.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 18.15.3.143
netmask 255.255.255.192
network 18.15.3.128
broadcast 18.15.3.191
gateway 18.15.3.129
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 8.8.8.8
dns-search fns.uniba.sk
# VLAN40 for DHCP server
auto eth0.40
iface eth0.40 inet static
address 18.15.5.150
netmask 255.255.255.0
#gateway 18.15.5.1
vlan-raw-device eth0
Na serveri bezia primarne dve sluzby. web-server a dhcp server. DHCP server funguje cez subnet vlan40 (18.15.5.0).
A este web server, ktory bezi na ip 18.15.3.143. Vsetko funguje dobre, ale ak sa chcem pripojit na web-server zo subnetu 18.15.5.0 (vlan40), tak stranku neotvori, okrem tohto subnetu sa dokaze pripojit na ten server cely svet. Akonahle ten interface eth0.40 vypnem tak sa uz dokaze subnet (18.15.5.0) pripojit.
tcpdump vypisuje toto:
15:31:55.005346 IP 18.15.5.160.59979 > domena.sk.https: Flags [S], seq 802408223, win 14600, options [mss 1460,sackOK,TS val 6133771 ecr 0,nop,wscale 6], length 0 15:31:55.209997 IP 18.15.5.160.59981 > domena.sk.https: Flags [S], seq 4125392294, win 14600, options [mss 1460,sackOK,TS val 6133791 ecr 0,nop,wscale 6], length 0 15:31:58.018442 IP 18.15.5.160.59979 > domena.sk.https: Flags [S], seq 802408223, win 14600, options [mss 1460,sackOK,TS val 6134072 ecr 0,nop,wscale 6], length 0
cely svet => 18.15.3.143 (pinguje) subnet 18.15.5.0 => 18.15.3.143 (NEpinguje) subnet 18.15.5.0 => 18.15.5.1 (pinguje)
1: lo: |LOOPBACK,UP,LOWER_UP| mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: |BROADCAST,MULTICAST,UP,LOWER_UP| mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 90:1b:0e:26:bc:9e brd ff:ff:ff:ff:ff:ff
inet xxx.xxx.xxx.xxx/26 brd xxx.xxx.xxx.xxx scope global eth0
valid_lft forever preferred_lft forever
inet6 xxx.xxx.xxx.xxx/64 scope link
valid_lft forever preferred_lft forever
3: eth1: |BROADCAST,MULTICAST| mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 90:1b:0e:24:39:a9 brd ff:ff:ff:ff:ff:ff
4: eth0.40@eth0: |BROADCAST,MULTICAST,UP,LOWER_UP| mtu 1500 qdisc noqueue state UP group default
link/ether 90:1b:0e:26:bc:9e brd ff:ff:ff:ff:ff:ff
inet xxx.xxx.xxx.xxx/24 brd 158.195.95.255 scope global eth0.40
valid_lft forever preferred_lft forever
inet6 xxx.xxx.xxx.xxx/64 scope link
valid_lft forever preferred_lft forever
tcpdump -nepi eth0 src xxx.xxx.xxx.xxx
09:06:09.779825 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 74: xxx.xxx.xxx.xxx.60747 > xxx.xxx.xxx.xxx.443: Flags [S], seq 3822164969, win 14600, options [mss 1460,sackOK,TS val 10446953 ecr 0,nop,wscale 6], length 0 09:06:12.777737 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 74: xxx.xxx.xxx.xxx.60747 > xxx.xxx.xxx.xxx.443: Flags [S], seq 3822164969, win 14600, options [mss 1460,sackOK,TS val 10447254 ecr 0,nop,wscale 6], length 0 09:06:18.803526 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 74: xxx.xxx.xxx.xxx.60747 > xxx.xxx.xxx.xxx.443: Flags [S], seq 3822164969, win 14600, options [mss 1460,sackOK,TS val 10447856 ecr 0,nop,wscale 6], length 0 09:06:18.956840 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 74: xxx.xxx.xxx.xxx.60746 > xxx.xxx.xxx.xxx.443: Flags [S], seq 4108988718, win 14600, options [mss 1460,sackOK,TS val 10447872 ecr 0,nop,wscale 6], length 0ip route show
default via xxx.xxx.xxx.xxx dev eth0 xxx.xxx.xxx.xxx/26 dev eth0 proto kernel scope link src xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx/24 dev eth0.40 proto kernel scope link src xxx.xxx.xxx.xxx
tcpdump je ze serveru nebo z klienta? Pokud píšete o IP adresách, je lepší tcpdump spustit s parametrem -n, protože můžeme jenom hádat, co je to domena.sk. Když si spustíte tcpdump na klientovi a na serveru, případně na routeru mezi nimi, měl byste zjistit sám, kde se pakety ztrácí. Jinak by bylo dobré dát sem z klienta i serveru výpis routovací tabulky (ip route), výpis firewallu a případně ty výpisy tcpdumpu.
Pokud píšete o IP adresách, je lepší tcpdump spustit s parametrem -n, protože můžeme jenom hádat, co je to domena.sk.
Stejně je skoro jistě falešné jak to doménové jméno, tak ty adresy, takže nemá smysl snažit se hádat nic. :-(
Místo konfiguračních souborů specifických pro nějakou distribuci raději ukažte, jak vypadá výstup
ip addr show ip route show
A samozřejmě skutečný výstup, ne náhodně pozměněný (nejste na MIT, že ne?).
tcpdump vypisuje toto
To je tcpdump spuštěný na kterém rozhraní? Co ukáže "tcpdump -nepi eth0"?
1: lo: |LOOPBACK,UP,LOWER_UP| mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: |BROADCAST,MULTICAST,UP,LOWER_UP| mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 90:1b:0e:26:bc:9e brd ff:ff:ff:ff:ff:ff
inet 158.195.93.143/26 brd 158.195.93.191 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::921b:eff:fe26:bc9e/64 scope link
valid_lft forever preferred_lft forever
3: eth1: |BROADCAST,MULTICAST| mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 90:1b:0e:24:39:a9 brd ff:ff:ff:ff:ff:ff
4: eth0.40@eth0: |BROADCAST,MULTICAST,UP,LOWER_UP| mtu 1500 qdisc noqueue state UP group default
link/ether 90:1b:0e:26:bc:9e brd ff:ff:ff:ff:ff:ff
inet 158.195.95.150/24 brd 158.195.95.255 scope global eth0.40
valid_lft forever preferred_lft forever
inet6 fe80::921b:eff:fe26:bc9e/64 scope link
valid_lft forever preferred_lft forever
tcpdump -nepi eth0 src 158.195.95.160
09:06:09.779825 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 74: 158.195.95.160.60747 > 158.195.93.143.443: Flags [S], seq 3822164969, win 14600, options [mss 1460,sackOK,TS val 10446953 ecr 0,nop,wscale 6], length 0 09:06:12.777737 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 74: 158.195.95.160.60747 > 158.195.93.143.443: Flags [S], seq 3822164969, win 14600, options [mss 1460,sackOK,TS val 10447254 ecr 0,nop,wscale 6], length 0 09:06:18.803526 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 74: 158.195.95.160.60747 > 158.195.93.143.443: Flags [S], seq 3822164969, win 14600, options [mss 1460,sackOK,TS val 10447856 ecr 0,nop,wscale 6], length 0 09:06:18.956840 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 74: 158.195.95.160.60746 > 158.195.93.143.443: Flags [S], seq 4108988718, win 14600, options [mss 1460,sackOK,TS val 10447872 ecr 0,nop,wscale 6], length 0ip route show
default via 158.195.93.129 dev eth0 158.195.93.128/26 dev eth0 proto kernel scope link src 158.195.93.143 158.195.95.0/24 dev eth0.40 proto kernel scope link src 158.195.95.150
Na ten interface vám chodí neotagované pakety, takže nerozumím tomu proč pro příslušnou adresu vytváříte VLAN interface. Viděl bych dvě možnosti:
(a) žádnou VLAN tam nemáte (nebo je implementována switchem jako z vašeho pohledu transparentní), takže nevytvářejte žádný VLAN interface a přidejte 158.195.95.150/24 prostě jako druhou adresu na eth0.
(b) chcete tam mít VLAN, ale v tom případě je potřeba nakonfigurovat zbytek sítě, aby pakety k vám chodily řádně otagované (a aby očekával otagované pakety od vás).
ak som to tak urobil
Co konkrétně znamená "to tak"? V příspěvku, na který odpovídáte, jsou dvě varianty.
nefunguje DHCP server
Co přesně znamená "nefunguje"?
ifconfig eth0:1 158.195.95.150 netmask 255.255.255.0 upifconfig
eth0:1 Link encap:Ethernet HWaddr 90:1b:0e:26:bc:9e
inet addr:158.195.95.150 Bcast:158.195.95.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:20 Memory:f7f00000-f7f20000
vypis z cisco portu, kde je server pripojeny:
vlan40 - subnet 158.195.95.0/24 (DHCP server)
vlan41 - subnet 158.195.93.128/26 (webserver)
show interfaces trunk
Port Mode Encapsulation Status Native vlan Fa0/30 on 802.1q trunking 41 Port Vlans allowed on trunk Fa0/30 40-41
Asi by to chtělo někoho, kdo rozumí konfiguraci toho Cisca, protože takhle to na mne působí, že by pakety z VLAN 40 měly chodit otagované, ale výstup tcpdumpu tomu neodpovídal. Leda že byste měl starou libpcap (IIRC starší než 1.0), která za určitých okolností neukazovala VLAN tagy.
Ale začíná to vypadat, že tam opravdu je plnohodnotná VLAN. Nemůže být problém prostě v tom, že klienti z 158.195.95.0/24 nevědí, že pakety pro 158.195.93.128 mají posílat na tento stroj?
Nemůže být problém prostě v tom, že klienti z 158.195.95.0/24 nevědí, že pakety pro 158.195.93.128 mají posílat na tento stroj?Předpokládám, že ten výše uvedený výpis z
tcpdump je ze serveru, takže tam pakety nějak dorazí, ale ze serveru neodejde odpověď. Pokud tam server opravdu naslouchá, napadají mne jen dvě možnosti – buď síťová vrstva paket odmítne, protože se domnívá, že jí nepatří, nebo paket dropuje firewall.
Zkuste si přidat na začátek řetězce INPUT pravidlo pro tuhle komunikaci (zdrojová a cílová IP adresa a port 80), a zjistěte, zda se při těch pokusech o komunikaci zvyšuje počítadlo paketů. Zjistíte tak, jestli pakety dorazí alespoň na firewall, nebo zda se ztratí už někde dřív.
iptables -A INPUT -s 158.195.93.143 -d 158.195.95.160 -p tcp --dport 80 -j ACCEPT iptables -A INPUT -s 158.195.93.143 -d 158.195.95.160 -p tcp --dport 443 -j ACCEPTtcpdump -nepi eth0 src 158.195.95.160
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 12:34:11.471941 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 74: 158.195.95.160.32835 > 158.195.93.143.443: Flags [S], seq 818147920, win 14600, options [mss 1460,sackOK,TS val 10829808 ecr 0,nop,wscale 6], length 0 12:34:11.706974 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 74: 158.195.95.160.32836 > 158.195.93.143.443: Flags [S], seq 2828444680, win 14600, options [mss 1460,sackOK,TS val 10829832 ecr 0,nop,wscale 6], length 0 12:34:12.479664 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 74: 158.195.95.160.32837 > 158.195.93.143.443: Flags [S], seq 812329448, win 14600, options [mss 1460,sackOK,TS val 10829909 ecr 0,nop,wscale 6], length 0 12:34:15.488135 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 74: 158.195.95.160.32837 > 158.195.93.143.443: Flags [S], seq 812329448, win 14600, options [mss 1460,sackOK,TS val 10830210 ecr 0,nop,wscale 6], length 0 12:34:21.505929 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 74: 158.195.95.160.32837 > 158.195.93.143.443: Flags [S], seq 812329448, win 14600, options [mss 1460,sackOK,TS val 10830812 ecr 0,nop,wscale 6], length 0alebo takto?
iptables -A INPUT -s 158.195.95.160 -d 158.195.93.143 -p tcp --dport 80 -j ACCEPT iptables -A INPUT -s 158.195.95.160 -d 158.195.93.143 -p tcp --dport 443 -j ACCEPT
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 12:36:27.672632 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 74: 158.195.95.160.32844 > 158.195.93.143.443: Flags [S], seq 2141428337, win 14600, options [mss 1460,sackOK,TS val 10842758 ecr 0,nop,wscale 6], length 0 12:36:30.205872 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 74: 158.195.95.160.32845 > 158.195.93.143.443: Flags [S], seq 3789358706, win 14600, options [mss 1460,sackOK,TS val 10843012 ecr 0,nop,wscale 6], length 0 12:36:33.223152 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 74: 158.195.95.160.32845 > 158.195.93.143.443: Flags [S], seq 3789358706, win 14600, options [mss 1460,sackOK,TS val 10843313 ecr 0,nop,wscale 6], length 0
iptables -nvL INPUTzda se tam nějaké pakety započítaly.
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT icmp -- eth0 * 158.195.93.207 0.0.0.0/0 icmptype 8 state NEW
0 0 ACCEPT icmp -- eth0 * 158.195.xx.xxx 0.0.0.0/0 icmptype 8 state NEW
0 0 ACCEPT icmp -- eth0 * 158.195.xx.xxx 0.0.0.0/0 icmptype 8 state NEW
0 0 ACCEPT tcp -- eth0 * 158.195.xx.xxx 0.0.0.0/0 tcp dpt:22 state NEW
0 0 ACCEPT tcp -- eth0 * 158.195.xx.xxx 0.0.0.0/0 tcp dpt:22 state NEW
0 0 ACCEPT tcp -- eth0 * 158.195.xx.xxx 0.0.0.0/0 tcp dpt:22 state NEW
0 0 ACCEPT tcp -- eth0 * 158.195.xx.xxx 0.0.0.0/0 tcp dpt:80 state NEW
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 state NEW
32 1696 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 state NEW
0 0 ACCEPT all -- lo * 127.0.0.1 0.0.0.0/0 state NEW
320 60620 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT tcp -- * * 158.195.93.143 158.195.95.160 tcp dpt:80
0 0 ACCEPT tcp -- * * 158.195.93.143 158.195.95.160 tcp dpt:443
To je zrovna ta špatná varianta, protože v INPUT by musela být cílová adresa vaše a zdrojová toho druhého. Navíc se ten paket tak daleko ani nedostane, protože ho acceptnete už o pár pravidel výš.
Ale pokud tam máte nějak netriviálně nakonfigurovaný paketový filtr, asi by stálo za to podívat se, jak vypadá OUTPUT.
iptables -A INPUT -s 158.195.95.160 -d 158.195.93.143 -p tcp --dport 80 -j ACCEPT iptables -A INPUT -s 158.195.95.160 -d 158.195.93.143 -p tcp --dport 443 -j ACCEPTiptables -nvL INPUT
Chain INPUT (policy DROP 6 packets, 813 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT icmp -- eth0 * 158.195.93.207 0.0.0.0/0 icmptype 8 state NEW
0 0 ACCEPT icmp -- eth0 * 158.195.93.200 0.0.0.0/0 icmptype 8 state NEW
0 0 ACCEPT icmp -- eth0 * 158.195.226.28 0.0.0.0/0 icmptype 8 state NEW
0 0 ACCEPT tcp -- eth0 * 158.195.93.207 0.0.0.0/0 tcp dpt:22 state NEW
0 0 ACCEPT tcp -- eth0 * 158.195.93.200 0.0.0.0/0 tcp dpt:22 state NEW
0 0 ACCEPT tcp -- eth0 * 158.195.226.28 0.0.0.0/0 tcp dpt:22 state NEW
0 0 ACCEPT tcp -- eth0 * 158.195.93.207 0.0.0.0/0 tcp dpt:80 state NEW
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 state NEW
61 3240 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 state NEW
0 0 ACCEPT all -- lo * 127.0.0.1 0.0.0.0/0 state NEW
594 113K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT tcp -- * * 158.195.95.160 158.195.93.143 tcp dpt:80
0 0 ACCEPT tcp -- * * 158.195.95.160 158.195.93.143 tcp dpt:443
iptables -nvL OUTPUT
Chain OUTPUT (policy ACCEPT 462 packets, 140K bytes) pkts bytes target prot opt in out source destination
# Generated by iptables-save v1.4.21 on Wed Nov 5 13:43:43 2014 *mangle :PREROUTING ACCEPT [6179:1087099] :INPUT ACCEPT [5671:1033322] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [5746:2071986] :POSTROUTING ACCEPT [5746:2071986] COMMIT # Completed on Wed Nov 5 13:43:43 2014 # Generated by iptables-save v1.4.21 on Wed Nov 5 13:43:43 2014 *nat :PREROUTING ACCEPT [1070:91164] :INPUT ACCEPT [505:26980] :OUTPUT ACCEPT [491:35210] :POSTROUTING ACCEPT [491:35210] COMMIT # Completed on Wed Nov 5 13:43:43 2014 # Generated by iptables-save v1.4.21 on Wed Nov 5 13:43:43 2014 *filter :INPUT DROP [56:10079] :FORWARD DROP [0:0] :OUTPUT ACCEPT [5110:1888602] :SSHDROP - [0:0] -A INPUT -s 158.195.93.207/32 -i eth0 -p icmp -m icmp --icmp-type 8 -m state --state NEW -j ACCEPT -A INPUT -s 158.195.93.200/32 -i eth0 -p icmp -m icmp --icmp-type 8 -m state --state NEW -j ACCEPT -A INPUT -s 158.195.226.28/32 -i eth0 -p icmp -m icmp --icmp-type 8 -m state --state NEW -j ACCEPT -A INPUT -s 158.195.93.207/32 -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT -A INPUT -s 158.195.93.200/32 -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT -A INPUT -s 158.195.226.28/32 -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT -A INPUT -s 158.195.93.207/32 -i eth0 -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT -A INPUT -p tcp -m tcp --dport 443 -m state --state NEW -j ACCEPT -A INPUT -s 127.0.0.1/32 -i lo -m state --state NEW -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -s 158.195.95.160/32 -d 158.195.93.143/32 -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -s 158.195.95.160/32 -d 158.195.93.143/32 -p tcp -m tcp --dport 443 -j ACCEPT -A SSHDROP -j LOG --log-prefix "SSH-pokus-DROP: " -A SSHDROP -j DROP COMMIT # Completed on Wed Nov 5 13:43:43 2014
Ano, ale jak už jsem řekl, ten paket se až k těm pravidlům nemá šanci dostat, protože máte o něco výš obecnější pravidla.
Zkuste ještě poté, co se pokusíte připojit na toho apache, na serveru spustit "ip neigh show" a podívat se, jestli je tam nějaká položka pro adresu klienta.
Potom ještě zkuste ping ze serveru na klienta, jak se bude chovat (hlavně jestli odejde paket ze serveru a jestli dorazí na klienta).
158.195.95.160 dev eth0 FAILEDping -I eth0.40 158.195.95.160 prejde ale ping -I eth0 158.195.95.160 uz neprejde, ale do ostatnych subnetov prejde bez problemov
To je celkem logické, ale otázka je, proč se vůbec snaží to posílat přes eth0, když podle routovací tabulky, kterou jste ukázal dříve, mají jít na eth0.40.
Jenom takové temné podezření: vidíte ty přicházející SYN pakety (pro Apache) i když posloucháte tcpdumpem na eth0.40?
iptables -A přidává pravidlo na konec a pravidla se vyhodnocují podle pořadí, v jakém jsou uvedena. Aby se určitě aplikovalo, psal jsme o jeho zařazení na začátek, takže by to bylo iptables -I INPUT 1.
Ale to teď už není podstatné. Opravdu ty pakety přicházejí tou VLAN 40? Jak psal Michal Kubeček, že starší verze libpcap nezobrazují VLANy – jakou verzi používáte? Měl by to ukázat příkaz ldd `which tcpdump`.
linux-vdso.so.1 => (0x00007fffa7113000)
libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f4c8405d000)
libpcap.so.0.8 => /usr/lib/x86_64-linux-gnu/libpcap.so.0.8 (0x00007f4c83e1f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4c83a58000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4c83854000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4c84892000)
V každém případě - problém je s tím, že když budeš mít na stroji IP z toho subnetu a požádáš o data z IP 158.195.93.143, bude se server snažit vrátit data nejkratší cestou, tedy přímo do subnetu přes VLANu, což klient nerozdejchá, protože přijdou úplně odjinud, než by je čekal. (Petr Merlin Vaněček)
libpcap.so.0.8 => /usr/lib/x86_64-linux-gnu/libpcap.so.0.8 (0x00007f4c83e1f000)
To by vysvětlovalo, proč tcpdump neukazuje vlan tag (pokud eth0 podporuje vlan offloading). Nechápu ovšem, proč má letos vydaná distribuce takhle historickou verzi libpcap.
V každém případě - problém je s tím, že když budeš mít na stroji IP z toho subnetu a požádáš o data z IP 158.195.93.143, bude se server snažit vrátit data nejkratší cestou, tedy přímo do subnetu přes VLANu, což klient nerozdejchá, protože přijdou úplně odjinud, než by je čekal.
S tím bych si dovolil nesouhlasit. Kdyby tohle byl důvod, tak by odpověď na SYN paket pořád ještě odešla ze serveru a teprve klient by ji zahodil - jenže podle tcpdumpu žádná neodejde (i kdyby odešla přes eth0.40, byly by pakety vidět i na eth0 (jen otagované)). Problém bude spíš v tom, že jestli SYN paket opravdu z nějakého důvodu přijde přes eth0 (neotagovaný) a jestli je zapnutý RP filter (což bohužel ve většině distribucí defaultně je), zahodí RP filter na serveru už přicházející SYN paket a žádná odpověď se tudíž neodešle. Proto jsem se ptal na to, jestli jsou příchozí SYN pakety vidět i na eth0.40 (případně by stálo za pokus vypnout RP filter (přinejmenším all a eth0)).
padě - problém je s tím, že když budeš mít na stroji IP z toho subnetu a požádáš o data z IP 158.195.93.143, bude se server snažit vrátit data nejkratší cestou, tedy přímo do subnetu přes VLANu, což klient nerozdejchá, protože přijdou úplně odjinud, než by je čekal. (Petr Merlin Vaněček)Proto jsem se na začátku ptal, jak vypadá routování v té síti, jestli klient komunikuje se serverem přímo, nebo jestli mezi nimi není nějaký router. A zda tam někde není NAT. Pokud ale klient má jen jedno rozhraní a pakety se nikde cestou neupravují, klient vůbec nepozná, že data přišla "odjinud" - dostane paket se správnými IP adresami na jediné rozhraní. Problém by byl, pokud by v cestě byl např. DNAT - pokud by paket cestou zpět šel jinudy, NAT se tam neprovede a klient dostane paket, který k ničemu nepatří. Navíc podle toho prvního výpisu tcpdumpu server vůbec neodpoví. Zkuste to na serveru ještě s testem
host místo src, ať opravdu vidíme celou komunikaci:
tcpdump -nepi eth0 host 158.195.95.160Nebo ať to není vázané na IP adresu, zkuste
tcpdump -nepi eth0 proto icmpa pingnout z klienta na server a ze serveru na klienta.
že starší verze libpcap nezobrazují VLANy
Ono to právě není úplně vždy, to je na tom nejvíc matoucí. Podle původu paketu a nastavených offloading flagů může libpcap buď dostat celý frame včetně vlan tagu nebo jen neotagovaný frame s tím, že informace z něj jsou v metadatech (tedy TCI, TPID bohužel až od jádra 3.13). Starší verze libpcap (IIRC před 1.0) zvládaly zpracovat vlan tagy jen v prvním případě. A pull request implementující správné zobrazení v případě, že TPID (různé od 0x8100) je předáno v metadatech, stále ještě čeká na githubu (někdy od dubna).
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 10:50:31.367588 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 74: 158.195.95.160 > 158.195.93.143: ICMP echo request, id 768, seq 1, length 40 10:50:40.660828 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 74: 158.195.95.160 > 158.195.93.143: ICMP echo request, id 770, seq 1, length 40 10:50:44.168003 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 74: 158.195.95.160 > 158.195.93.143: ICMP echo request, id 771, seq 1, length 40 10:50:48.327397 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 74: 158.195.95.160 > 158.195.93.143: ICMP echo request, id 772, seq 1, length 40tcpdump -nepi eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 10:52:07.634891 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 74: 158.195.95.160 > 158.195.93.143: ICMP echo request, id 783, seq 1, length 40 10:52:09.248196 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 74: 158.195.95.160 > 158.195.93.143: ICMP echo request, id 784, seq 1, length 40 10:52:10.086611 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 82: 158.195.93.129 > 158.195.93.143: ICMP host 158.195.47.241 unreachable, length 48 10:52:16.792974 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 74: 158.195.95.160 > 158.195.93.143: ICMP echo request, id 785, seq 1, length 40 10:52:20.366147 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 74: 158.195.95.160 > 158.195.93.143: ICMP echo request, id 786, seq 1, length 40 10:52:23.174549 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 82: 158.195.93.129 > 158.195.93.143: ICMP host 158.195.47.241 unreachable, length 48 10:52:24.589103 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 74: 158.195.95.160 > 158.195.93.143: ICMP echo request, id 787, seq 1, length 40 10:52:36.262182 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 82: 158.195.93.129 > 158.195.93.143: ICMP host 158.195.47.241 unreachable, length 48 10:52:39.678048 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 74: 158.195.95.160 > 158.195.93.143: ICMP echo request, id 788, seq 1, length 40 10:52:41.286526 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 74: 158.195.95.160 > 158.195.93.143: ICMP echo request, id 789, seq 1, length 40 10:52:48.851394 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 74: 158.195.95.160 > 158.195.93.143: ICMP echo request, id 790, seq 1, length 40 10:52:49.350556 00:1b:21:b9:86:ed > 90:1b:0e:26:bc:9e, ethertype IPv4 (0x0800), length 82: 158.195.93.129 > 158.195.93.143: ICMP host 158.195.47.241 unreachable, length 48
eth0, ale kvůli staré libpcap nevíme, jestli jsou otagované nebo ne, dokud ten tcpdump nezkusíte pustit na eth0.40. A nevidíme žádné odcházející, ale to jsme neviděli ani předtím, takže taky nic nového.
tcpdump -nepi eth0.40 icmp tak nic nezachyti. Mam aktualizovat libpcap?
Ne kvůli tomuhle. To prostě znamená, že ty pakety opravdu přicházejí neotagované, takže platí, co jsem psal včera v 16:31. Takže v každém případě vypnout RP filter (nejlépe všude, určitě eth0 a all) a pokud máte nějakou jeho obdobu na druhé straně (a nedá se vypnout), můžete zkusit něco jako
ip route add 158.195.95.0/24 via 158.195.93.129 table 100 ip rule add priority 1000 from 158.195.93.143 table 100
Alternativou by mohlo být nastavit těm klientům z 158.195.95.0/24, aby routovali 158.195.93.143 přes 158.195.95.150
ip route add 158.195.95.0/24 via 158.195.93.129 table 100
ip rule add priority 1000 from 158.195.93.143 table 100
IMHO je problém spíš tom, že stroje z VLAN 40 nevědí, že ta adresa z jiného rozsahu je tam s nimi vlastně taky, takže paket pošlou na nějakou default gateway a ta ho odroutuje přes VLAN 41, která je ale na tom portu nastavena jako transparentní (nebo jak tomu u Cisca říkají). Tím, že se zařídí, aby šla odpověď stejnou cestou (plus vypnout RP filter, aby se nezahodil už příchozí paket), se problém obejde.
Ostatně soudím, že RP filter je zlo.
Tiskni
Sdílej:
