Portál AbcLinuxu, 5. května 2025 23:23
#iptables script #!/bin/bash echo 1 > /proc/sys/net/ipv4/ip_forward iptables --flush iptables -t nat --flush iptables -A POSTROUTING -t nat -o eth0 -s 192.168.1.0/24 -j MASQUERADE iptables -A FORWARD -i eth1 -s 192.168.1.0/24 -j ACCEPT iptables -A POSTROUTING -t nat -o eth0 -s 192.168.2.0/24 -j MASQUERADE iptables -A FORWARD -i eth2 -s 192.168.2.0/24 -j ACCEPT iptables -A POSTROUTING -t nat -o eth0 -s 192.168.3.0/24 -j MASQUERADE iptables -A FORWARD -i eth3 -s 192.168.3.0/24 -j ACCEPT
#/etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo eth1 eth2 eth3 iface lo inet loopback # The primary network interface allow-hotplug eth0 iface eth0 inet dhcp iface eth1 inet static address 192.168.1.254 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 mtu 1500 iface eth2 inet static address 192.168.2.254 netmask 255.255.255.0 network 192.168.2.0 broadcast 192.168.2.255 mtu 1500 iface eth3 inet static address 192.168.3.254 netmask 255.255.255.0 network 192.168.3.0 broadcast 192.168.3.255 mtu 1500
#/etc/dhcp/dhcpd.conf # # Sample configuration file for ISC dhcpd for Debian # # # The ddns-updates-style parameter controls whether or not the server will # attempt to do a DNS update when a lease is confirmed. We default to the # behavior of the version 2 packages ('none', since DHCP v2 didn't # have support for DDNS.) ddns-update-style none; # option definitions common to all supported networks... #option domain-name "example.org"; #option domain-name-servers ns1.example.org, ns2.example.org; default-lease-time 600; max-lease-time 7200; # If this DHCP server is the official DHCP server for the local # network, the authoritative directive should be uncommented. authoritative; # Use this to send dhcp log messages to a different log file (you also # have to hack syslog.conf to complete the redirection). log-facility local7; # No service will be given on this subnet, but declaring it helps the # DHCP server to understand the network topology. #subnet 10.152.187.0 netmask 255.255.255.0 { #} # This is a very basic subnet declaration. #subnet 10.254.239.0 netmask 255.255.255.224 { # range 10.254.239.10 10.254.239.20; # option routers rtr-239-0-1.example.org, rtr-239-0-2.example.org; #} # This declaration allows BOOTP clients to get dynamic addresses, # which we don't really recommend. #subnet 10.254.239.32 netmask 255.255.255.224 { # range dynamic-bootp 10.254.239.40 10.254.239.60; # option broadcast-address 10.254.239.31; # option routers rtr-239-32-1.example.org; #} # A slightly different configuration for an internal subnet. #subnet 10.5.5.0 netmask 255.255.255.224 { # range 10.5.5.26 10.5.5.30; # option domain-name-servers ns1.internal.example.org; # option domain-name "internal.example.org"; # option routers 10.5.5.1; # option broadcast-address 10.5.5.31; # default-lease-time 600; # max-lease-time 7200; #} # Hosts which require special configuration options can be listed in # host statements. If no address is specified, the address will be # allocated dynamically (if possible), but the host-specific information # will still come from the host declaration. #host passacaglia { # hardware ethernet 0:0:c0:5d:bd:95; # filename "vmunix.passacaglia"; # server-name "toccata.fugue.com"; #} # Fixed IP addresses can also be specified for hosts. These addresses # should not also be listed as being available for dynamic assignment. # Hosts for which fixed IP addresses have been specified can boot using # BOOTP or DHCP. Hosts for which no fixed address is specified can only # be booted with DHCP, unless there is an address range on the subnet # to which a BOOTP client is connected which has the dynamic-bootp flag # set. #host fantasia { # hardware ethernet 08:00:07:26:c0:a5; # fixed-address fantasia.fugue.com; #} # You can declare a class of clients and then do address allocation # based on that. The example below shows a case where all clients # in a certain class get addresses on the 10.17.224/24 subnet, and all # other clients get addresses on the 10.0.29/24 subnet. #class "foo" { # match if substring (option vendor-class-identifier, 0, 4) = "SUNW"; #} #shared-network 224-29 { # subnet 10.17.224.0 netmask 255.255.255.0 { # option routers rtr-224.example.org; # } # subnet 10.0.29.0 netmask 255.255.255.0 { # option routers rtr-29.example.org; # } # pool { # allow members of "foo"; # range 10.17.224.10 10.17.224.250; # } # pool { # deny members of "foo"; # range 10.0.29.10 10.0.29.230; # } #} subnet 192.168.1.0 netmask 255.255.255.0 { range 192.168.1.10 192.168.1.253; option domain-name-servers 88.212.8.8, 88.212.8.88; option domain-name "siet_1"; option routers 192.168.1.254; option broadcast-address 192.168.1.255; } subnet 192.168.2.0 netmask 255.255.255.0 { range 192.168.2.10 192.168.2.253; option domain-name-servers 88.212.8.8, 88.212.8.88; option domain-name "siet_2"; option routers 192.168.2.254; option broadcast-address 192.168.2.255; } subnet 192.168.3.0 netmask 255.255.255.0 { range 192.168.3.10 192.168.3.253; option domain-name-servers 88.212.8.8, 88.212.8.88; option domain-name "siet_3"; option routers 192.168.3.254; option broadcast-address 192.168.3.255; }
Řešení dotazu:
allow-hotplug eth0
bych používal auto eth0
. Když tam zůstane to první, tak při resetu interfaces se eth0 neresetne Jde vidět, že o tom balíčku nic nevíte, co vše dělá a jak a taky jak se možné konfigurace modifikovat.Tuším, že jsem ho před mnoha lety zkoušel, ale máte naprostou pravdu. O tom balíčku prakticky nic nevím a nevím ani k čemu je. Ale myslím, že chyba není na mé straně. V dokumentaci je úplně na začátku sekce „Purpose“, kde se píše toto:
ipmasq is a system to securely initialize IP Masquerade for use as a forwarding firewall. IP Masquerade is a feature of the Linux kernel that allows an entire network of computers to be connected to another network (usually the Internet) with only one network address on that other network. IP Masquerade is often referred to as NAT (Network Address Translation) on other platforms.Pouze první věta je o ipmasq. A teda sorry. Bezpečně inicializovat IP maškarádu pro použítí jako router s firewallem (volně), umím pár řádky ve skriptu. Když zadám ipmasq do googlu, tak mi z toho nic zajímavého nevypadne. Na packages.debian.org říkají, že navíc můžu ty skripty upravit. Proč, když si tak jednoduchý skript zvládnu napsat sám? Co si tak matně pamatuju, tak ipmasq byl balíček hlavně pro ty, co se bojí iptables a chtějí jednoduchý NAT. Můžete mě odkazem na relevantní zdroj přesvědčit o opaku.
iptables -n -L iptables -t nat -n -L ip a ip rPotom se uvidi. ps. Doufam ze z gw ti internet jde
#iptables -n -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT all -- 192.168.1.0/24 0.0.0.0/0 ACCEPT all -- 192.168.2.0/24 0.0.0.0/0 ACCEPT all -- 192.168.3.0/24 0.0.0.0/0 Chain OUTPUT (policy ACCEPT) target prot opt source destination
#iptables -t nat -n -L Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination MASQUERADE all -- 192.168.1.0/24 0.0.0.0/0 MASQUERADE all -- 192.168.2.0/24 0.0.0.0/0 MASQUERADE all -- 192.168.3.0/24 0.0.0.0/0 Chain OUTPUT (policy ACCEPT) target prot opt source destination root@furca:~#
#ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 98:4b:e1:10:98:de brd ff:ff:ff:ff:ff:ff
inet 10.0.169.69/24 brd 10.0.169.255 scope global eth0
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
link/ether 00:22:64:8a:42:8f brd ff:ff:ff:ff:ff:ff
inet 192.168.1.254/24 brd 192.168.1.255 scope global eth1
4: eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
link/ether 00:26:55:e3:8f:c0 brd ff:ff:ff:ff:ff:ff
inet 192.168.2.254/24 brd 192.168.2.255 scope global eth2
5: eth3: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
link/ether 00:26:55:e3:8f:c1 brd ff:ff:ff:ff:ff:ff
inet 192.168.3.254/24 brd 192.168.3.255 scope global eth3
#ip r 192.168.3.0/24 dev eth3 proto kernel scope link src 192.168.3.254 192.168.2.0/24 dev eth2 proto kernel scope link src 192.168.2.254 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.254 10.0.169.0/24 dev eth0 proto kernel scope link src 10.0.169.69 default via 10.0.169.1 dev eth0
echo 1 > ..pote se koukni zda je v jednicce prez
dej echo "1" > /proc/sys/net/ipv4/ip_forward
cat /proc...
eth1: NO-CARRIER,BROADCAST,MULTICAST,UP mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
Divný - jako by síťovky eth1-3 neměly link. Možná nechoděj interrupty a driver se o linku nedozví, nebo něco podobného. Problém bych hledal na této vrstvě, IP nastavení vypadá OK.
Kouknout do dmesgu jestli tam neni neco podezřelýho.
Co říká ethtool / mii-tool?
Předpokládám, že ani klienti nedostanou od serveru přes DHCP adresu.
Nejdřív se snažit uchodit komunikaci mezi serverem a klienty na lokální síti, pak teprve zkoušet routování do Internetu.
Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on MDI-X: Unknown Supports Wake-on: g Wake-on: g Current message level: 0x000000ff (255) Link detected: yes
Settings for eth1: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Speed: Unknown! Duplex: Unknown! (255) Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on MDI-X: Unknown Supports Wake-on: pumbag Wake-on: d Current message level: 0x00000001 (1) Link detected: no
Settings for eth2: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Speed: Unknown! Duplex: Unknown! (255) Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on MDI-X: Unknown Supports Wake-on: pumbag Wake-on: g Current message level: 0x00000001 (1) Link detected: no
Settings for eth3: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Speed: Unknown! Duplex: Unknown! (255) Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on MDI-X: Unknown Supports Wake-on: d Wake-on: d Current message level: 0x00000001 (1) Link detected: no
Jednoznačně kříženej vs. nekříženej kabel.. Počítače (plus routery, což jsou spešl počítače) pracují na 3. vrstvě. Proto když se spojí nekříženým kabelem, tak vysílací páry na jedný straně jdou do vysílacích párů na druhé straně (to samé i pro přijímací) a zařízení se nevidí. Když to hodíte přes SW a použijete nekřížený kabel, vše bude v cajku, protože SW pracují na druhé vrstvě a mají vysílací a přijímací stranu přehozenouDůvod proč špatná kombinace karet/kebelů nefunguje, že Tx jde do Tx je správně. Ale s tím, jestli je zařízení L2 nebo L3 to nemá vůbec nic společného. Switche prostě mají většinou fíčuru zvanou auto-mdix, takže dokážou zdetekovat, na kterých drátech se má vysílat a na kterých přijímat a funguje to proto s normálním i kříženým kabelem a se síťovkou nebo jiným switchem na jeho druhém konci. 10 a 100 Mbit síťovky zpravidla tuto fíčuru nemají, proto pří propojování dvou síťovek je potřeba křížený kabel a jinak to nebude fungovat. Gigabitové síťovky tuto fíčuru naopak (vždy?) mají, a proto pokud je jedna ze síťovek gigabitová, měl by jít použít i přímý kabel. S L2/L3 to nemá společného nic. Zařízení klidně může být třeba ten router, který má 1 port co se chová jako síťovka a auto-mdix neumí a 4 porty, co se chovají jako switch a auto-mdix umí.
No, hádat se nebudu. Přečtěte si oficiální e-learningové materiály Cisco na zkoušku CCNA-1 a tam je to pěkně vysvětleno...Předpokládám, že v cisco materiálech snad nebude takový nesmysl, jako že by auto-mdix mělo něco společného s třetí vrstvou OSI.
Ale v RFC normách a specifikacích stojí toto a JE TO PRAVDA.Ve kterých RFC konkrétně? Čísla?
Můžu se mýlit. Ale mám opravdu pocit, že jsem to v nějakém RFC četl. Ale to je jedno.Není ani důvod, aby to v nějakém bylo, vzhledem k tomu, že RFC se Ethernetem zabývají jen v největší nouzi, a jen když se má něco postavit nad Ethernetem. Maximálně mohl tu poučku někdo střelit do nějakého „slepého střeva“.
Já toto používám proto, protože to funguje.Je to něco jako trojčlenka, umí se tím vyřešit pár základních typů úloh, když člověk nic jiného neumí.
A Cisco asi taky ví, o čem mluví.Ale jistě, Cisco je velký argument. Ale na manažerském webu by to byl mnohem větší argument než tady.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.