Du må være registrert og logget inn for å kunne legge ut innlegg på freak.no
X
LOGG INN
... eller du kan registrere deg nå
Dette nettstedet er avhengig av annonseinntekter for å holde driften og videre utvikling igang. Vi liker ikke reklame heller, men alternativene er ikke mange. Vær snill å vurder å slå av annonseblokkering, eller å abonnere på en reklamefri utgave av nettstedet.
  18 4957
Hei.
Jeg driver og "hacker" litt.
Fra Canal Digital får vi maks 4 offentlige dynamiske IP-adresser.

Jeg har flere LAN-klienter i subnettet 192.168.1.1 - 192.168.1.254.

Jeg deler ut 192.168.1.100 - 192.168.1.200 til DHCP-klienter.

Tre av maskinene som er tilkoblet LAN-et er satt opp med hver sin statiske IP-adresse:
192.168.1.10
192.168.1.15
192.168.1.20

Linux-boksen har to nettverkskort, et kort som er koblet direkte på modemet, og et som er koblet på en lokal switch slik at klientene internt i nettverket får nett.

Jeg har opprettet tre virtuelle interfaces:

Kode

ip link add link enp0s25 address 00:11:22:33:44:55 virtual0 type macvlan
ip link set virtual0 up
ip link add link enp0s25 address 00:11:22:33:44:56 virtual1 type macvlan
ip link set virtual1 up
ip link add link enp0s25 address 00:11:22:33:44:57 virtual2 type macvlan
ip link set virtual2 up
dhclient virtual0
dhclient virtual1
dhclient virtual2
enp0s25 er nettverkskortet som er koblet direkte på modemet.

Dette fungerer, og jeg har altså nettverkskortene virtual0, virtual1 og virtual2 som får hver sin offentlige IP-adresse. Disse IP-adressene svarer ikke på ping utenfra, kun IP-adressen som er tildelt enp0s25.

Jeg ønsker også at de tre statiske LAN-klientene kun skal ha IP-adressene som er på virtual0,1,2,3

Altså:
192.168.1.10 skal kun routes gjennom virtual0
192.168.1.15 skal kun routes gjennom virtual1
192.168.1.20 skal kun routes gjennom virtual2

På denne måten vil i praksis de tre LAN-klientene ha hver sin egen offentlige IP-adresse, men samtidig være i samme subnett som resten av klientene. Tøft, ikke sant?

Dette er skriptet jeg har prøvd å lage:

Kode

ip link add link enp0s25 address 00:11:22:33:44:55 virtual0 type macvlan
ip link set virtual0 up
ip link add link enp0s25 address 00:11:22:33:44:56 virtual1 type macvlan
ip link set virtual1 up
ip link add link enp0s25 address 00:11:22:33:44:57 virtual2 type macvlan
ip link set virtual2 up
dhclient virtual0
dhclient virtual1
dhclient virtual2

iptables -t nat -A PREROUTING -i virtual0 -j DNAT --to-destination 192.168.1.10
iptables -t nat -A PREROUTING -i virtual1 -j DNAT --to-destination 192.168.1.15
iptables -t nat -A PREROUTING -i virtual2 -j DNAT --to-destination 192.168.1.20

export IP1=`ip -4 addr show virtual0 | grep -oP '(?<=inet\s)\d+(\.\d+){3}'`
export IP2=`ip -4 addr show virtual1 | grep -oP '(?<=inet\s)\d+(\.\d+){3}'`
export IP3=`ip -4 addr show virtual2 | grep -oP '(?<=inet\s)\d+(\.\d+){3}'`

iptables -t nat -A PREROUTING -d $IP1 -j DNAT --to-destination 192.168.1.10
iptables -t nat -A POSTROUTING -d 192.168.1.10 -j SNAT --to $IP1

iptables -t nat -A PREROUTING -d $IP2 -j DNAT --to-destination 192.168.1.15
iptables -t nat -A POSTROUTING -d 192.168.1.15 -j SNAT --to $IP2

iptables -t nat -A PREROUTING -d $IP3 -j DNAT --to-destination 192.168.1.20
iptables -t nat -A POSTROUTING -d 192.168.1.20 -j SNAT --to $IP3
Jeg fant fort ut at ingen av klientene, hverken de statiske eller de dynamiske fikk Internett, så jeg puttet på brannmurregelen:

-A POSTROUTING -o enp0s25 -j MASQUERADE

Slik ser nå brannmurreglene ut:

Kode

*nat
:PREROUTING ACCEPT [888:195205]
:INPUT ACCEPT [396:38971]
:OUTPUT ACCEPT [1883:141001]
:POSTROUTING ACCEPT [24:1206]
-A PREROUTING -d 46.x.x.x/32 -j DNAT --to-destination 192.168.1.10
-A PREROUTING -d 46.x.x.x/32 -j DNAT --to-destination 192.168.1.15
-A PREROUTING -d 95.x.x.x/32 -j DNAT --to-destination 192.168.1.20
-A POSTROUTING -d 192.168.1.10/32 -j SNAT --to-source 46.x.x.x
-A POSTROUTING -d 192.168.1.15/32 -j SNAT --to-source 47.x.x.x
-A POSTROUTING -d 192.168.1.20/32 -j SNAT --to-source 96.x.x.x
-A POSTROUTING -o enp0s25 -j MASQUERADE
-A POSTROUTING -o virtual0 -j MASQUERADE
COMMIT
# Completed on Fri Oct 20 10:13:18 2017
Da fikk alle klientene Internett, både de dynamiske og de statiske.
Men hvordan tvinger jeg trafikken til de statiske LAN-klientene til å kun gå gjennom virtual 0, 1 og 2?

Hva er det jeg mangler? Er dette i det hele tatt mulig å gjennomføre?
Sist endret av Rusmisbrukeren; 20. oktober 2017 kl. 11:18.
Du har ikke behov for PREROUTING reglene all den tid du ikke ønsker innkommende trafikk fra internett. Du behøver i grunnen bare 1 linjer pr virtuelle interface, og jeg ville heller brukt MASQUERADE isteden for SNAT. Og du har også satt 192.168.1.1X statiske IP adressene med en subnet maske tilsvarende 255.255.255.255 som blir feil, såfremt ikke de statiske IP adressene er konfigurert med ovennevnt subnet maske.

Kode

iptables -t nat -A POSTROUTING -s 192.168.1.10 -o virtual0 -j MASQUERADE
I tilegg trenger du denne linjen på slutten for å tillatte andre enheter (ikke tidligere spesifiserte) å kommunisere med internett:

Kode

iptables -t nat -A POSTROUTING -o enp0s25 -j MASQUERADE
Og denne for å tillate forward trafikk fra LAN interfacen.

Kode

iptables -A FORWARD -i <LAN_INTERFACE> -j ACCEPT
Du må også aktivere ip_forwarding.

Kode

sysctl -w net.ipv4.ip_forward=1
Tror jeg har husket alt, er en stund siden jeg har drevet på med IP routing.
Sist endret av 0xFF; 20. oktober 2017 kl. 13:55.
Hei!
Takk for hjelp, jeg har nå rettet opp dette, slik at firewall-rules nå ser sånn ut:

Kode

# Generated by iptables-save v1.6.0 on Wed Oct 25 09:35:53 2017
*nat
:PREROUTING ACCEPT [17:1298]
:INPUT ACCEPT [6:416]
:OUTPUT ACCEPT [214:14736]
:POSTROUTING ACCEPT [5:303]
-A POSTROUTING -s 192.168.10.0/24 -o virtual0 -j MASQUERADE
-A POSTROUTING -s 192.168.10.0/24 -o virtual1 -j MASQUERADE
-A POSTROUTING -s 192.168.10.0/24 -o virtual2 -j MASQUERADE
-A POSTROUTING -o enp0s25 -j MASQUERADE
COMMIT
# Completed on Wed Oct 25 09:35:53 2017
# Generated by iptables-save v1.6.0 on Wed Oct 25 09:35:53 2017
*mangle
:PREROUTING ACCEPT [598:231914]
:INPUT ACCEPT [464:121713]
:FORWARD ACCEPT [130:109961]
:OUTPUT ACCEPT [559:38661]
:POSTROUTING ACCEPT [689:148622]
COMMIT
# Completed on Wed Oct 25 09:35:53 2017
# Generated by iptables-save v1.6.0 on Wed Oct 25 09:35:53 2017
*filter
:INPUT ACCEPT [459:119785]
:FORWARD ACCEPT [61:104587]
:OUTPUT ACCEPT [565:39621]
-A FORWARD -i enp4s0 -j ACCEPT
COMMIT
# Completed on Wed Oct 25 09:35:53 2017
IPV4 forward er 1.

Jeg satte så min egen PC til å ha 192.168.10.10 som statisk IP. Sjekket så ipadresse.no, og der kom kun IP-adressen som serveren har, ikke den jeg skulle hatt (den til virtual0), men jeg oppdaget nå at det står noe feil i kodesnuttet jeg la ut tidligere:

Kode

-A POSTROUTING -s 192.168.10.0/24 -o virtual0 -j MASQUERADE
-A POSTROUTING -s 192.168.10.0/24 -o virtual1 -j MASQUERADE
-A POSTROUTING -s 192.168.10.0/24 -o virtual2 -j MASQUERADE
IP-adressene skulle ikke sluttet på 10.0, men 10.10, 10.15, 10.20.

Jeg endret skriptet som genererte dette til:

Kode

ip link add link enp0s25 address 00:11:22:33:44:55 virtual0 type macvlan
ip link set virtual0 up
ip link add link enp0s25 address 00:11:22:33:44:56 virtual1 type macvlan
ip link set virtual1 up
ip link add link enp0s25 address 00:11:22:33:44:57 virtual2 type macvlan
ip link set virtual2 up
dhclient virtual0
dhclient virtual1
dhclient virtual2

iptables -t nat -A POSTROUTING -s 192.168.10.10/24 -o virtual0 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 192.168.10.15/24 -o virtual1 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 192.168.10.20/24 -o virtual2 -j MASQUERADE
iptables -t nat -A POSTROUTING -o enp0s25 -j MASQUERADE
iptables -A FORWARD -i enp4s0 -j ACCEPT
iptables commit
Siden du reagerte på at det var /32 bak adressene tidligere, satte jeg like greit /24 etter IP, men det ser ut til å ha gjort sånn at IP-adressene ser ut som 10.0 alle sammen.

Noen tips?
Sitat av Rusmisbrukeren Vis innlegg
Hei!
Takk for hjelp, jeg har nå rettet opp dette, slik at firewall-rules nå ser sånn ut:

Kode

[...]
-A POSTROUTING -s 192.168.10.0/24 -o virtual0 -j MASQUERADE
-A POSTROUTING -s 192.168.10.0/24 -o virtual1 -j MASQUERADE
-A POSTROUTING -s 192.168.10.0/24 -o virtual2 -j MASQUERADE
[...]
Vis hele sitatet...
Jeg sjekket det opp hvordan iptables håndterer spesifikke node adresser, og jeg har nok villedet deg i forrige post. Du kan bruker /32, Men når du refererer til en enkel node på nettverket så er det ikke behov for subnet prefix størrelse. IPTables legger automatisk til riktig subnet prefix størrelse når du lagrer reglene med iptables-save

Kode

ip link add link enp0s25 address 00:11:22:33:44:55 virtual0 type macvlan
ip link set virtual0 up
ip link add link enp0s25 address 00:11:22:33:44:56 virtual1 type macvlan
ip link set virtual1 up
ip link add link enp0s25 address 00:11:22:33:44:57 virtual2 type macvlan
ip link set virtual2 up
dhclient virtual0
dhclient virtual1
dhclient virtual2

iptables -t nat -A POSTROUTING -s 192.168.10.10 -o virtual0 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 192.168.10.15 -o virtual1 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 192.168.10.20 -o virtual2 -j MASQUERADE
iptables -t nat -A POSTROUTING -o enp0s25 -j MASQUERADE
iptables -A FORWARD -i enp4s0 -j ACCEPT
iptables commit
Sist endret av 0xFF; 25. oktober 2017 kl. 11:13.
Takk for svar!
Ser ut til at vi må fundere litt mer på dette, for nå er min iptables sånn:

Kode

enp0s25: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 84.XXX.XXX.XXX  netmask 255.255.255.0  broadcast 84.XXX.XXX.255
        inet6 fe80::225:64ff:fed3:9270  prefixlen 64  scopeid 0x20<link>
        ether 00:25:64:d3:92:70  txqueuelen 1000  (Ethernet)
        RX packets 2702  bytes 1314393 (1.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2722  bytes 322503 (314.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 21  memory 0xf7ae0000-f7b00000

enp4s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.10.3  netmask 255.255.255.0  broadcast 192.168.10.255
        inet6 fe80::230:f1ff:fe33:836d  prefixlen 64  scopeid 0x20<link>
        ether 00:30:f1:33:83:6d  txqueuelen 1000  (Ethernet)
        RX packets 1143  bytes 189355 (184.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1230  bytes 762325 (744.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

virtual0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 46.X.XX.XXX  netmask 255.255.255.0  broadcast 46.X.XX.255
        inet6 fe80::211:22ff:fe33:4455  prefixlen 64  scopeid 0x20<link>
        ether 00:11:22:33:44:55  txqueuelen 1000  (Ethernet)
        RX packets 20  bytes 6000 (5.8 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 11  bytes 2106 (2.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

virtual1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 46.X.X.XXX  netmask 255.255.255.0  broadcast 46.X.X.255
        inet6 fe80::211:22ff:fe33:4456  prefixlen 64  scopeid 0x20<link>
        ether 00:11:22:33:44:56  txqueuelen 1000  (Ethernet)
        RX packets 14  bytes 4794 (4.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 11  bytes 1642 (1.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

virtual2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 95.XX.XX.XXX  netmask 255.255.255.0  broadcast 95.XX.XX.255
        inet6 fe80::211:22ff:fe33:4457  prefixlen 64  scopeid 0x20<link>
        ether 00:11:22:33:44:57  txqueuelen 1000  (Ethernet)
        RX packets 17  bytes 4974 (4.8 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 10  bytes 1572 (1.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
Og når jeg nå kjører iptables-save, får jeg dette:

Kode

# Generated by iptables-save v1.6.0 on Wed Oct 25 10:30:55 2017
*nat
:PREROUTING ACCEPT [258:48942]
:INPUT ACCEPT [123:9966]
:OUTPUT ACCEPT [1219:87605]
:POSTROUTING ACCEPT [16:992]
-A POSTROUTING -s 192.168.10.10/32 -o virtual0 -j MASQUERADE
-A POSTROUTING -s 192.168.10.15/32 -o virtual1 -j MASQUERADE
-A POSTROUTING -s 192.168.10.20/32 -o virtual2 -j MASQUERADE
-A POSTROUTING -o enp0s25 -j MASQUERADE
COMMIT
# Completed on Wed Oct 25 10:30:55 2017
# Generated by iptables-save v1.6.0 on Wed Oct 25 10:30:55 2017
*mangle
:PREROUTING ACCEPT [5177:1862642]
:INPUT ACCEPT [2317:678762]
:FORWARD ACCEPT [2832:1182336]
:OUTPUT ACCEPT [2361:187657]
:POSTROUTING ACCEPT [5193:1369993]
COMMIT
# Completed on Wed Oct 25 10:30:55 2017
# Generated by iptables-save v1.6.0 on Wed Oct 25 10:30:55 2017
*filter
:INPUT ACCEPT [2311:676794]
:FORWARD ACCEPT [1606:953478]
:OUTPUT ACCEPT [2363:188233]
-A FORWARD -i enp4s0 -j ACCEPT
COMMIT
# Completed on Wed Oct 25 10:30:55 2017
PC-en min er konfigurert til å ha:
IP: 192.168.10.10
NMASK: 255.255.255.0
GW: 192.168.10.3

Likevel får jeg IP-adressen på enp0s25, og ikke virtual0 (sjekker på ipadresse.no), som jeg skulle hatt.
Det må mangle noe, er det noe vi har glemt her tror du?

Må også legge til: All trafikk som skal gå fra 192.168.10.10 skal UT av virtual0 også, men det regner jeg med at reglene du har gitt meg ordner også?
Vanskelig å feilsøke over et forum. Men du kan prøve å kjøre følgende kommando fra terminalen:

Kode

iptables -t nat -I POSTROUTING -s 192.168.10.10 -m state --state NEW -j LOG --log-prefix "[+] NEW POSTROUTING: "
Og sjekke om du finner noen linjer som starter med «[+] NEW POSTROUTING:» i /var/log/syslog mens du surfer fra maskinen med IP 192.168.10.10:

Kode

tail -f /var/log/syslog
EDIT: Dette vil fortelle oss hvorvidt pakkene kommer fram til POSTROUTING chain.
Sist endret av 0xFF; 25. oktober 2017 kl. 11:53.
God morgen!
La meg ned og sov litt
Nå har jeg gjort det du ba meg om.

Kode

Oct 25 12:49:18 gateway kernel: [ 8625.934228] [+] NEW POSTROUTING: IN= OUT=enp0s25 SRC=192.168.10.10 DST=176.9.67.12 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=4090 DF PROTO=TCP SPT=57390 DPT=443 WINDOW=64240 RES=0x00 SYN URGP=0
Oct 25 12:49:21 gateway kernel: [ 8628.566690] [+] NEW POSTROUTING: IN= OUT=enp0s25 SRC=192.168.10.10 DST=216.58.211.142 LEN=1378 TOS=0x00 PREC=0x00 TTL=127 ID=19790 DF PROTO=UDP SPT=60389 DPT=443 LEN=1358
Oct 25 12:49:21 gateway kernel: [ 8628.620234] [+] NEW POSTROUTING: IN= OUT=enp0s25 SRC=192.168.10.10 DST=212.125.204.230 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=27006 DF PROTO=TCP SPT=57391 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0
Oct 25 12:49:21 gateway kernel: [ 8628.620348] [+] NEW POSTROUTING: IN= OUT=enp0s25 SRC=192.168.10.10 DST=212.125.204.230 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=27007 DF PROTO=TCP SPT=57392 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0
Oct 25 12:49:21 gateway kernel: [ 8628.620374] [+] NEW POSTROUTING: IN= OUT=enp0s25 SRC=192.168.10.10 DST=212.125.204.230 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=27008 DF PROTO=TCP SPT=57393 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0
Oct 25 12:49:21 gateway kernel: [ 8628.620433] [+] NEW POSTROUTING: IN= OUT=enp0s25 SRC=192.168.10.10 DST=212.125.204.230 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=27009 DF PROTO=TCP SPT=57394 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0
Oct 25 12:49:21 gateway kernel: [ 8628.620453] [+] NEW POSTROUTING: IN= OUT=enp0s25 SRC=192.168.10.10 DST=212.125.204.230 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=27010 DF PROTO=TCP SPT=57395 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0
Oct 25 12:49:21 gateway kernel: [ 8628.620484] [+] NEW POSTROUTING: IN= OUT=enp0s25 SRC=192.168.10.10 DST=212.125.204.230 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=27011 DF PROTO=TCP SPT=57396 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0
Oct 25 12:49:22 gateway named[845]: network unreachable resolving 'ns-g1.agdernett.no/AAAA/IN': 2001:7fe::53#53
Oct 25 12:49:22 gateway named[845]: network unreachable resolving 'ns1.agdernett.no/AAAA/IN': 2001:7fe::53#53
Oct 25 12:49:22 gateway named[845]: network unreachable resolving 'ns2.agdernett.no/AAAA/IN': 2001:7fe::53#53
Oct 25 12:49:22 gateway named[845]: network unreachable resolving 'ns3.agdernett.no/AAAA/IN': 2001:7fe::53#53
Oct 25 12:49:22 gateway named[845]: network unreachable resolving 'ns5.agdernett.no/AAAA/IN': 2001:7fe::53#53
Oct 25 12:49:22 gateway named[845]: network unreachable resolving 'ns6.agdernett.no/AAAA/IN': 2001:7fe::53#53
Oct 25 12:49:22 gateway named[845]: network unreachable resolving './NS/IN': 2001:7fe::53#53
Oct 25 12:49:22 gateway kernel: [ 8630.386342] [+] NEW POSTROUTING: IN= OUT=enp0s25 SRC=192.168.10.10 DST=195.88.55.87 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=1219 DF PROTO=TCP SPT=57397 DPT=443 WINDOW=64240 RES=0x00 SYN URGP=0
Vil for øvrig informere om at jeg ikke har noe imot i å la deg fjernstyre denne serveren for å eventuelt hjelpe meg hvis du orker / ønsker det. Ellers kan vi fortsette å holde oss til disse forumpostene

Ser at det står OUT=enp0s25, og det er jo hovednettverkskortet på serveren, ikke virtual0.

Forklarer dette deg noe? Hvordan løser jeg det herfra?

PS: Dette er output fra da jeg besøkte ipadresse.no
Sist endret av Rusmisbrukeren; 25. oktober 2017 kl. 13:56.
Sitat av Rusmisbrukeren Vis innlegg
God morgen!
La meg ned og sov litt
Nå har jeg gjort det du ba meg om.

Kode

Oct 25 12:49:18 gateway kernel: [ 8625.934228] [+] NEW POSTROUTING: IN= OUT=enp0s25 SRC=192.168.10.10 DST=176.9.67.12 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=4090 DF PROTO=TCP SPT=57390 DPT=443 WINDOW=64240 RES=0x00 SYN URGP=0
Oct 25 12:49:21 gateway kernel: [ 8628.566690] [+] NEW POSTROUTING: IN= OUT=enp0s25 SRC=192.168.10.10 DST=216.58.211.142 LEN=1378 TOS=0x00 PREC=0x00 TTL=127 ID=19790 DF PROTO=UDP SPT=60389 DPT=443 LEN=1358
Oct 25 12:49:21 gateway kernel: [ 8628.620234] [+] NEW POSTROUTING: IN= OUT=enp0s25 SRC=192.168.10.10 DST=212.125.204.230 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=27006 DF PROTO=TCP SPT=57391 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0
Oct 25 12:49:21 gateway kernel: [ 8628.620348] [+] NEW POSTROUTING: IN= OUT=enp0s25 SRC=192.168.10.10 DST=212.125.204.230 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=27007 DF PROTO=TCP SPT=57392 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0
Oct 25 12:49:21 gateway kernel: [ 8628.620374] [+] NEW POSTROUTING: IN= OUT=enp0s25 SRC=192.168.10.10 DST=212.125.204.230 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=27008 DF PROTO=TCP SPT=57393 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0
Oct 25 12:49:21 gateway kernel: [ 8628.620433] [+] NEW POSTROUTING: IN= OUT=enp0s25 SRC=192.168.10.10 DST=212.125.204.230 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=27009 DF PROTO=TCP SPT=57394 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0
Oct 25 12:49:21 gateway kernel: [ 8628.620453] [+] NEW POSTROUTING: IN= OUT=enp0s25 SRC=192.168.10.10 DST=212.125.204.230 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=27010 DF PROTO=TCP SPT=57395 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0
Oct 25 12:49:21 gateway kernel: [ 8628.620484] [+] NEW POSTROUTING: IN= OUT=enp0s25 SRC=192.168.10.10 DST=212.125.204.230 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=27011 DF PROTO=TCP SPT=57396 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0
Oct 25 12:49:22 gateway named[845]: network unreachable resolving 'ns-g1.agdernett.no/AAAA/IN': 2001:7fe::53#53
Oct 25 12:49:22 gateway named[845]: network unreachable resolving 'ns1.agdernett.no/AAAA/IN': 2001:7fe::53#53
Oct 25 12:49:22 gateway named[845]: network unreachable resolving 'ns2.agdernett.no/AAAA/IN': 2001:7fe::53#53
Oct 25 12:49:22 gateway named[845]: network unreachable resolving 'ns3.agdernett.no/AAAA/IN': 2001:7fe::53#53
Oct 25 12:49:22 gateway named[845]: network unreachable resolving 'ns5.agdernett.no/AAAA/IN': 2001:7fe::53#53
Oct 25 12:49:22 gateway named[845]: network unreachable resolving 'ns6.agdernett.no/AAAA/IN': 2001:7fe::53#53
Oct 25 12:49:22 gateway named[845]: network unreachable resolving './NS/IN': 2001:7fe::53#53
Oct 25 12:49:22 gateway kernel: [ 8630.386342] [+] NEW POSTROUTING: IN= OUT=enp0s25 SRC=192.168.10.10 DST=195.88.55.87 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=1219 DF PROTO=TCP SPT=57397 DPT=443 WINDOW=64240 RES=0x00 SYN URGP=0
Vil for øvrig informere om at jeg ikke har noe imot i å la deg fjernstyre denne serveren for å eventuelt hjelpe meg hvis du orker / ønsker det. Ellers kan vi fortsette å holde oss til disse forumpostene

Ser at det står OUT=enp0s25, og det er jo hovednettverkskortet på serveren, ikke virtual0.

Forklarer dette deg noe? Hvordan løser jeg det herfra?

PS: Dette er output fra da jeg besøkte ipadresse.no
Vis hele sitatet...
Trafikken kommer jo tydelig fram til NAT POSTROUTING chain, så eneste forslaget jeg har igjen er å prøve SNAT igjen istedenfor MASQUERADE. Selv om SNAT er beregnet for statisk IP.

Kode

ip link add link enp0s25 address 00:11:22:33:44:55 virtual0 type macvlan
ip link set virtual0 up
ip link add link enp0s25 address 00:11:22:33:44:56 virtual1 type macvlan
ip link set virtual1 up
ip link add link enp0s25 address 00:11:22:33:44:57 virtual2 type macvlan
ip link set virtual2 up
dhclient virtual0
dhclient virtual1
dhclient virtual2
    
iptables -t nat -A POSTROUTING -s 192.168.10.10 -o enp0s25 -j SNAT --to-source <VIRTUAL0 IP>
iptables -t nat -A POSTROUTING -s 192.168.10.15 -o enp0s25 -j SNAT --to-source <VIRTUAL1 IP>
iptables -t nat -A POSTROUTING -s 192.168.10.20 -o enp0s25 -j SNAT --to-source <VIRTUAL2 IP>
iptables -t nat -A POSTROUTING -o enp0s25 -j MASQUERADE
iptables -A FORWARD -i enp4s0 -j ACCEPT
iptables commit
Hvis ikke dette fungerer, så tror jeg du må spørre noen som driver på dette regelmessig og har bedre kunnskaper innen IP basert routing enn meg.
0xFF: Tusen takk! Det siste fungerte KUDOS, KP og for alltid credits til deg!
Deler nå med resten av forumet hvordan skriptet ser ut

/etc/network/interfaces:

Kode

# The primary network interface
allow-hotplug enp0s25
iface enp0s25 inet dhcp
        post-up iptables-restore < /etc/iptables.up.rules
        post-up ip6tables-restore < /etc/ip6tables.up.rules
        post-up /etc/init.d/virtualinterfaces4

allow-hotplug enp4s0
iface enp4s0 inet static
        address 192.168.10.3
        netmask 255.255.255.0
        broadcast 192.168.10.255
/etc/init.d/virtualinterfaces4

Kode

ip link add link enp0s25 address 00:11:22:33:44:55 virtual0 type macvlan
ip link set virtual0 up
ip link add link enp0s25 address 00:11:22:33:44:56 virtual1 type macvlan
ip link set virtual1 up
ip link add link enp0s25 address 00:11:22:33:44:57 virtual2 type macvlan
ip link set virtual2 up
dhclient virtual0
dhclient virtual1
dhclient virtual2

export IP1=`ip -4 addr show virtual0 | grep -oP '(?<=inet\s)\d+(\.\d+){3}'`
export IP2=`ip -4 addr show virtual1 | grep -oP '(?<=inet\s)\d+(\.\d+){3}'`
export IP3=`ip -4 addr show virtual2 | grep -oP '(?<=inet\s)\d+(\.\d+){3}'`
#echo $IP1 $IP2 $IP3 - Ble bare brukt for å verifisere.
iptables -t nat -A POSTROUTING -s 192.168.10.10 -o enp0s25 -j SNAT --to-source $IP1
iptables -t nat -A POSTROUTING -s 192.168.10.15 -o enp0s25 -j SNAT --to-source $IP2
iptables -t nat -A POSTROUTING -s 192.168.10.20 -o enp0s25 -j SNAT --to-source $IP3
iptables -t nat -A POSTROUTING -o enp0s25 -j MASQUERADE
iptables -A FORWARD -i enp4s0 -j ACCEPT
#iptables commit - ikke i bruk lenger, får error "unknown argument commit", så fjernet.
Endret lokal IP til 192.168.10.10, og fikk virtual0 IP på ipadresse.no
Endret lokal IP til 192.168.10.15, og fikk virtual1 IP på ipadresse.no
Endret lokal IP til 192.168.10.20, og fikk virtual3 IP på ipadresse.no

Tusen hjertelig takk!
Fungerer fjell!
Sist endret av Rusmisbrukeren; 26. oktober 2017 kl. 09:02. Grunn: Automatisk sammenslåing med etterfølgende innlegg.
Da er jeg tilbake med enda en problemstilling. De lokale IP-adressene er nemlig webservere og lignende.
Det er meningen at når man besøker en nettside som er pekt til $IP1, så skal man komme til serveren 192.168.10.10.

Prøvde derfor disse iptables-reglene:

Kode

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.10.10:80
iptables -t nat -A POSTROUTING -p tcp -d 192.168.10.10 --dport 80 -j SNAT --to-source $IP1

iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination 192.168.10.10:443
iptables -t nat -A POSTROUTING -p tcp -d 192.168.10.10 --dport 443 -j SNAT --to-source $IP1
Dette fungerer fjell! Men problemet er at jeg også sitter på samme lokalnett, og dette er DHCP-serveren som deler ut IP-adresser til mine klienter. Det betyr at hver gang jeg besøker en nettside med SSL (https://...), så får jeg feilmelding om at det er usikkert å besøke nettsiden.

Da jeg sjekket hva som sto i sertifikatet til nettsiden jeg forsøkte å besøke, så oppdaget jeg at den brukte sertifikatet som ligger på webserveren til den websiden jeg hoster, på 192.168.10.10...

Så... Hva skal til for at dette ikke skjer med IP-adressene som ikke er nevnt i firewall-rulen, for eksempel min PC, som har IP 192.168.10.105?

Jeg har blitt bedt om å være mer spesifikk, så jeg prøver en gang til med mer detaljer:
Serveren jeg har lagt iptables-reglene du har hjulpet meg med, denne serveren er en gateway for mitt hjemmenett. Den har DHCP-server installert (Debian), og deler ut IP-adresser i rangen 192.168.10.100 - 192.168.10.199.

Jeg har en annen server på dette nettverket, den har statisk IP 192.168.10.8.
Iptables-reglene 0xFF har hjulpet meg med ser sånn ut:

Kode

# Generated by iptables-save v1.6.0 on Tue Oct 31 06:17:34 2017
*nat
:PREROUTING ACCEPT [15551:1816287]
:INPUT ACCEPT [6753:699040]
:OUTPUT ACCEPT [13036:965202]
:POSTROUTING ACCEPT [243:12443]
-A POSTROUTING -s 192.168.10.8/32 -o enp0s25 -j SNAT --to-source XXX.XXX.XXX.118
-A POSTROUTING -s 192.168.10.9/32 -o enp0s25 -j SNAT --to-source XXX.XXX.XXX.164
-A POSTROUTING -s 192.168.10.10/32 -o enp0s25 -j SNAT --to-source XXX.XXX.XXX.181
-A POSTROUTING -o enp0s25 -j MASQUERADE
COMMIT
# Completed on Tue Oct 31 06:17:34 2017
# Generated by iptables-save v1.6.0 on Tue Oct 31 06:17:34 2017
*mangle
:PREROUTING ACCEPT [292173:146503099]
:INPUT ACCEPT [53686:12638536]
:FORWARD ACCEPT [238187:133846563]
:OUTPUT ACCEPT [34126:11931844]
:POSTROUTING ACCEPT [272252:145772719]
COMMIT
# Completed on Tue Oct 31 06:17:34 2017
# Generated by iptables-save v1.6.0 on Tue Oct 31 06:17:34 2017
*filter
:INPUT ACCEPT [53686:12638536]
:FORWARD ACCEPT [238187:133846563]
:OUTPUT ACCEPT [34065:11926156]
COMMIT
# Completed on Tue Oct 31 06:17:34 2017
Så altså, når jeg besøker ipadresse.no (med CURL) fra den serveren med 192.168.10.8, har den IP-adressen XXX.XXX.XXX.118. Dette er helt riktig og i henhold til trådens problemstilling.

Så inne i Cloudflare DNS har jeg satt domenet minegenside.no til å peke til XXX.XXX.XXX.118, slik at når man besøker minegenside.no, skal man komme til denne serveren (192.168.10.8)

Da måtte jeg legge inn disse kommandoene i firewall:

Kode

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.10.8:80
iptables -t nat -A POSTROUTING -p tcp -d 192.168.10.8 --dport 80 -j SNAT --to-source XXX.XXX.XXX.118

iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination 192.168.10.8:443
iptables -t nat -A POSTROUTING -p tcp -d 192.168.10.8 --dport 443 -j SNAT --to-source XXX.XXX.XXX.118
Dette fungerer perfekt, alle som besøker minegenside.no blir videresendt til riktig server, og alt fungerer som det skal.
Problemet er at når jeg besøker https://google.no, eller https://freak.no eller you name it, fra min PC, med IP-adressen 192.168.100.105, så blir jeg faktisk sendt til minegenside.no. Nå mens jeg skriver dette oppdaget jeg at det også gjelder http://-adresser, altså både port 80 og 443..... Alle sidene jeg på min PC besøker, er minegenside.no ....
Bilde: https://imgur.com/a/uFQ0b
Iptables-regler mens dette problemet er aktuell:

Kode

# Generated by iptables-save v1.6.0 on Tue Oct 31 06:31:03 2017
*nat
:PREROUTING ACCEPT [360:127266]
:INPUT ACCEPT [232:21306]
:OUTPUT ACCEPT [367:26679]
:POSTROUTING ACCEPT [5:244]
-A PREROUTING -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.10.8:80
-A PREROUTING -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.10.8:443
-A POSTROUTING -s 192.168.10.8/32 -o enp0s25 -j SNAT --to-source XXX.XXX.XXX.118
-A POSTROUTING -s 192.168.10.9/32 -o enp0s25 -j SNAT --to-source XXX.XXX.XXX.164
-A POSTROUTING -s 192.168.10.10/32 -o enp0s25 -j SNAT --to-source XXX.XXX.XXX.181
-A POSTROUTING -o enp0s25 -j MASQUERADE
-A POSTROUTING -d 192.168.10.8/32 -p tcp -m tcp --dport 80 -j SNAT --to-source XXX.XXX.XXX.118
-A POSTROUTING -d 192.168.10.8/32 -p tcp -m tcp --dport 443 -j SNAT --to-source XXX.XXX.XXX.118
COMMIT
# Completed on Tue Oct 31 06:31:03 2017
# Generated by iptables-save v1.6.0 on Tue Oct 31 06:31:03 2017
*mangle
:PREROUTING ACCEPT [313040:160499689]
:INPUT ACCEPT [55171:12975593]
:FORWARD ACCEPT [257559:147505496]
:OUTPUT ACCEPT [35205:12053907]
:POSTROUTING ACCEPT [292665:159548134]
COMMIT
# Completed on Tue Oct 31 06:31:03 2017
# Generated by iptables-save v1.6.0 on Tue Oct 31 06:31:03 2017
*filter
:INPUT ACCEPT [55171:12975593]
:FORWARD ACCEPT [257559:147505496]
:OUTPUT ACCEPT [35106:12042638]
COMMIT
# Completed on Tue Oct 31 06:31:03 2017
Dette skjer også på web-serveren i seg selv, jeg skriver f.eks. curl -s ipv4.icanhazip.com i terminalen, da skal man egentlig bare få sin egen IP-adresse. Nå får jeg hele HTML-koden til forsiden til minegenside.no i output i terminal isteden..
Sist endret av Rusmisbrukeren; 31. oktober 2017 kl. 07:48. Grunn: Automatisk sammenslåing med etterfølgende innlegg.
Her er feilen:

Kode

-A PREROUTING -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.10.8:80
Du har satt opp en preroutings regel med dynamisk nat som peker til 192.168.10.8:80, men du spesifiserer jo ikke input interface. Så den peker alle interface mot 192.168.10.8:80, virtual0, virtual1, virtual2, enp0s25, og LAN side interfacen.

Regelen skal se slik ut:

Kode

-A PREROUTING -i virtual0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.10.8:80
Da har jeg testet dette, nå ser iptables slik ut:

Kode

# Generated by iptables-save v1.6.0 on Tue Oct 31 14:03:30 2017
*nat
:PREROUTING ACCEPT [277:48324]
:INPUT ACCEPT [135:10449]
:OUTPUT ACCEPT [795:56939]
:POSTROUTING ACCEPT [19:1082]
-A PREROUTING -i virtual0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.10.8:80
-A PREROUTING -i virtual0 -p tcp -m tcp --dport 10000 -j DNAT --to-destination 192.168.10.8:10000
-A PREROUTING -i virtual0 -p tcp -m tcp --dport 3000 -j DNAT --to-destination 192.168.10.8:3000
-A PREROUTING -i virtual0 -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.10.8:443
-A POSTROUTING -s 192.168.10.8/32 -o enp0s25 -j SNAT --to-source XXX.XXX.XXX.118
-A POSTROUTING -s 192.168.10.9/32 -o enp0s25 -j SNAT --to-source XXX.XXX.XXX.164
-A POSTROUTING -s 192.168.10.10/32 -o enp0s25 -j SNAT --to-source XXX.XXX.XXX.181
-A POSTROUTING -d 192.168.10.8/32 -p tcp -m tcp --dport 80 -j SNAT --to-source XXX.XXX.XXX.118
-A POSTROUTING -d 192.168.10.8/32 -p tcp -m tcp --dport 10000 -j SNAT --to-source XXX.XXX.XXX.118
-A POSTROUTING -d 192.168.10.8/32 -p tcp -m tcp --dport 3000 -j SNAT --to-source XXX.XXX.XXX.118
-A POSTROUTING -d 192.168.10.8/32 -p tcp -m tcp --dport 443 -j SNAT --to-source XXX.XXX.XXX.118
-A POSTROUTING -o enp0s25 -j MASQUERADE
COMMIT
# Completed on Tue Oct 31 14:03:30 2017
# Generated by iptables-save v1.6.0 on Tue Oct 31 14:03:30 2017
*mangle
:PREROUTING ACCEPT [5665:1914745]
:INPUT ACCEPT [1809:450909]
:FORWARD ACCEPT [3848:1463356]
:OUTPUT ACCEPT [1912:166714]
:POSTROUTING ACCEPT [5760:1630070]
COMMIT
# Completed on Tue Oct 31 14:03:30 2017
# Generated by iptables-save v1.6.0 on Tue Oct 31 14:03:30 2017
*filter
:INPUT ACCEPT [1807:450790]
:FORWARD ACCEPT [1957:1043271]
:OUTPUT ACCEPT [1910:166567]
-A FORWARD -i enp4s0 -j ACCEPT
COMMIT
# Completed on Tue Oct 31 14:03:30 2017
Dette hadde ingen effekt. Jeg kan surfe som normalt på internett osv, men når man går på minside.no, kommer man til routeren, man blir ikke videresendt til 192.168.10.8.. Flere tips?
Gikk litt fort i morrest. Slik skal den se ut, legg merke til at den hører til NAT kjeden.

Kode

-A PREROUTING -t nat -i virtual0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.10.8:80
Og du må også ha en forward regel.

Kode

-A FORWARD -p tcp -m tcp -d 192.168.10.8 --dport 80 -j ACCEPT
Du kan også spesifisere forward regelen ytterligere ved å legge til (men det er ikke nødvendig for å få det til å fungere)

Kode

-i virtual0
-o <LAN INTERFACE>
-m state --state NEW,ESTABLISHED,RELATED
Denne reglene gir ingen mening.

Kode

-A POSTROUTING -d 192.168.10.8/32 -p tcp -m tcp --dport 80 -j SNAT --to-source XXX.XXX.XXX.118
Du ønsker å endre source adressen i pakkene til en adresse som er kjent innenfor nettverket. Altså 192.168.10.8

Kode

-A POSTROUTING -d 192.168.10.8/32 -p tcp -m tcp --dport 80 -j SNAT --to-source 192.168.10.8
Men jeg ville ha prøvd med MASQUERADE før SNAT.

Kode

-A POSTROUTING -o <LAN INTERFACE> -j MASQUERADE
Nå er iptables-reglene slik:

Kode

# Generated by iptables-save v1.6.0 on Tue Oct 31 17:09:53 2017
*nat
:PREROUTING ACCEPT [55:4585]
:INPUT ACCEPT [22:2471]
:OUTPUT ACCEPT [475:33354]
:POSTROUTING ACCEPT [17:965]
-A PREROUTING -i virtual0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.10.8:80
-A PREROUTING -i virtual0 -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.10.8:443
-A POSTROUTING -o enp0s25 -j MASQUERADE
-A POSTROUTING -o enp4s0 -j MASQUERADE
-A POSTROUTING -s 192.168.10.8/32 -o enp0s25 -j SNAT --to-source XXX.XXX.XXX.118
-A POSTROUTING -s 192.168.10.9/32 -o enp0s25 -j SNAT --to-source XXX.XXX.XXX.164
-A POSTROUTING -s 192.168.10.10/32 -o enp0s25 -j SNAT --to-source XXX.XXX.XXX.181
COMMIT
# Completed on Tue Oct 31 17:09:53 2017
# Generated by iptables-save v1.6.0 on Tue Oct 31 17:09:53 2017
*mangle
:PREROUTING ACCEPT [1615:508196]
:INPUT ACCEPT [1074:261993]
:FORWARD ACCEPT [539:246083]
:OUTPUT ACCEPT [1298:93673]
:POSTROUTING ACCEPT [1837:339756]
COMMIT
# Completed on Tue Oct 31 17:09:53 2017
# Generated by iptables-save v1.6.0 on Tue Oct 31 17:09:53 2017
*filter
:INPUT ACCEPT [1068:261551]
:FORWARD ACCEPT [261:193787]
:OUTPUT ACCEPT [1292:93257]
-A FORWARD -i enp4s0 -j ACCEPT
-A FORWARD -d 192.168.10.8/32 -p tcp -m tcp --dport 80 -j ACCEPT
-A FORWARD -d 192.168.10.8/32 -p tcp -m tcp --dport 443 -j ACCEPT
COMMIT
# Completed on Tue Oct 31 17:09:53 2017
Fremdeles ingen forward Sjekket for sikkerhets skyld om ipv4 forward er aktivert, og det er det..
Dette er så merkelig. Med mindre jeg har misforstått deg og laget feil regler nå?
Som jeg tidligere påpekte så er jeg ingen ekspert innen ip routing og iptables. Men hvis gir meg SSH tilgang, så er det lettere for meg, da jeg kan se hvordan trafikken oppfører seg med forskjellige reglene. Du kan sende SSH info på PM, så skal jeg se på det i kveld når jeg for tid. Er blant annet usikker på hvorvidt du trenger postroutings regel for portforwarding.
Ikke noe problem. Sender SSH info.

Da har jeg og 0xFF i samarbeid på serveren klart å få til AKKURAT ønsket resultat.
/etc/network/interfaces:

Kode

# The loopback network interface
auto lo enp4s0 enp0s25 virtual0
iface lo inet loopback

# The primary network interface
allow-hotplug enp0s25
iface enp0s25 inet dhcp
        post-up iptables-restore < /etc/iptables.up.rules
        post-up ip6tables-restore < /etc/ip6tables.up.rules
        post-up /etc/virtualinterfaces.sh

allow-hotplug enp4s0
iface enp4s0 inet static
        address 192.168.10.4
        netmask 255.255.255.0
        broadcast 192.168.10.255
Legg merke til:

Kode

post-up /etc/virtualinterfaces.sh
Denne kjører dette skriptet når enp0s25 (hovedinternett) er oppe:

/etc/virtualinterfaces.sh

Kode

ip link add link enp0s25 address 00:11:22:33:44:55 virtual0 type macvlan
ip link set virtual0 up
ip link add link enp0s25 address 00:11:22:33:44:56 virtual1 type macvlan
ip link set virtual1 up
ip link add link enp0s25 address 00:11:22:33:44:57 virtual2 type macvlan
ip link set virtual2 up
dhclient virtual0
dhclient virtual1
dhclient virtual2

export mainip=`ip -4 addr show enp0s25 | grep -oP '(?<=inet\s)\d+(\.\d+){3}'`
export IP1=`ip -4 addr show virtual0 | grep -oP '(?<=inet\s)\d+(\.\d+){3}'`
export IP2=`ip -4 addr show virtual1 | grep -oP '(?<=inet\s)\d+(\.\d+){3}'`
export IP3=`ip -4 addr show virtual2 | grep -oP '(?<=inet\s)\d+(\.\d+){3}'`
echo $mainip > /etc/mainip.txt
echo $IP1 > /etc/ip1.txt
echo $IP2 > /etc/ip2.txt
echo $IP3 > /etc/ip3.txt
iptables -t nat -A POSTROUTING -s 192.168.10.8 -o enp0s25 -j SNAT --to-source $IP1
iptables -t nat -A POSTROUTING -s 192.168.10.9 -o enp0s25 -j SNAT --to-source $IP2
iptables -t nat -A POSTROUTING -s 192.168.10.10 -o enp0s25 -j SNAT --to-source $IP3

#MINSIDE.NO SERVER IPTABLES
iptables -t nat -A PREROUTING -d $IP1 -j DNAT --to-destination 192.168.10.8
iptables -t nat -A POSTROUTING -d 192.168.10.8 -j SNAT --to $IP1

#LAST
#iptables -t nat -A POSTROUTING -o enp0s25 -j MASQUERADE // fjernet fordi den ikke trengs.
iptables -A FORWARD -i enp4s0 -j ACCEPT
Resultat:
Klientene som velger å ha 192.168.10.8 får virtual0 IP ved å besøke ipadresse.no
Klientene som velger å ha 192.168.10.9 får virtual1 IP ved å besøke ipadresse.no
Klientene som velger å ha 192.168.10.10 får virtual2 IP ved å besøke ipadresse.no

192.168.10.8 er gitt til webserveren til minside.no, og nå videresendes all trafikk på virtual0 IP til 192.168.10.8, så alt fungerer akkurat som ønsket.

Tusen, tusen hjertelig takk til 0xFF for all hjelp!

Neste steg: Cloudflare API, oppdatere DNS-records ut ifra /etc/mainip.txt, /etc/ip1.txt, /etc/ip2.txt, /etc/ip3.txt.
Dette skal jeg klare selv
Sist endret av Rusmisbrukeren; 1. november 2017 kl. 10:52. Grunn: Automatisk sammenslåing med etterfølgende innlegg.
Nå er jeg tilbake.
Da jeg og 0xFF fikset på dette her, så satt vi hjemme hos meg med nett fra Canal Digital. Her er det coax.
Da vi var ferdig med oppsettet, flyttet jeg serverne til et annet sted med nett fra Canal Digital, hvor det er fiber.

Der fungerer dette ikke. Jeg har prøvd å flytte serverne tilbake hit, og da fungerte det. Så flytta jeg dem tilbake til fiberen, der fungerte det ikke.

Jeg finner ingen logisk årsak til at dette skulle fungere her, men ikke på det andre stedet hvor oppsettet, utstyret og alt annet er akkurat det samme, bortsett fra at det er en fiberboks istedenfor coaxmodem?

Symptomene man merker er at alle virtual-interfaces får IP-adresse, det fungerer, men man får ikke svar fra IP-adressene i det hele tatt, hverken på ping eller andre ting. Dette gjelder uansett om trafikken forwardes til de lokale IP-adressene eller kun brukes av router-serveren i seg selv.

Jeg har akkurat samme oppsett på en annen server her hjemme, her er det som sagt coax. Her får man svar på ping fra alle interfaces, og alt fungerer som det skal her.

Er det noe Canal Digital har gjort?

BTW: Tracerouten hjemmefra er litt annerledes enn på fiberstedet.
Hjemmefra (med coax, sol.no):

Kode

  1    <1 ms    <1 ms    <1 ms  192.168.10.4
  2     7 ms     5 ms     7 ms  10.160.64.1
  3     7 ms    25 ms     6 ms  ti0006a400-xe1-1-0.ti.telenor.net [193.212.176.125]
  4    13 ms    14 ms    14 ms  ti0005c400-ae4-0.ti.telenor.net [146.172.102.57]
  5    15 ms    14 ms    13 ms  ti0001c360-ae77-0.ti.telenor.net [146.172.98.197]
  6    13 ms    13 ms    12 ms  ti0300b400-ae1-0.ti.telenor.net [146.172.105.50]
  7    13 ms    15 ms    14 ms  185.1.55.41
  8    13 ms    14 ms    14 ms  104.20.57.217
Ignorer hopp 1, den er der fordi jeg kjørte denne tracerouten fra min pc som er innenfor LAN. Det er hopp 2 man skal reagere på, jeg har ingen enhet her med den IP-adressen, og det er ikke IP-adressen som dukker opp på WAN i routeren (public ip dukker opp). Altså: Det fins en lokal IP som sitter etter modemet mitt, sannsynligvis fordi Canal Digital bruker dette til management.

Se på tracerouten fra fiberstedet, mot sol.no:

Kode

traceroute to sol.no (104.20.56.217), 30 hops max, 60 byte packets
 1  ti0006a400.ti.telenor.net (146.172.70.17)  1.130 ms  1.120 ms  1.110 ms
 2  ti0006c400-ae8-0.ti.telenor.net (146.172.18.29)  9.609 ms  9.611 ms  9.600 ms
 3  ti0300c360-ae77-0.ti.telenor.net (146.172.98.221)  27.359 ms  27.415 ms  27.412 ms
 4  ti0300b400-ae0-0.ti.telenor.net (146.172.105.102)  11.741 ms  11.746 ms  11.735 ms
 5  185.1.55.41 (185.1.55.41)  8.952 ms  8.923 ms  8.888 ms
Denne tracerouten er kjørt direkte fra den aktuelle serveren, derfor er det ingen lokal IP som første hopp, men legg merke til at andre hopp ikke er en lokal IP heller. Dette går «rett på nett».

Kan dette ha noe med problemet å gjøre? Kan det være på grunn av MAC-adressen jeg har tildelt de virtuelle interfacene? De er jo helt åpenbart ikke «ekte» MAC-adresser. 00:11:22:33:44:55...
Sist endret av Rusmisbrukeren; 6. november 2017 kl. 23:43. Grunn: Automatisk sammenslåing med etterfølgende innlegg.
Jeg har ikke tid til å se på det i kveld. Men jeg kan forklare traceroute outputene dine kort.

Hopp nr 2 på første og hopp nr 1 på andre output er gatewayen til Canal Digital, altså dit din gateway henvender seg for å route trafikken videre.

Dette kan du bekrefte ved å kjøre (fra gateway serveren din):

Kode

route -n
Da vil du se noe sånt som:

Kode

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.160.64.1     0.0.0.0         UG    0      0        0 enp0s25
                ^^^^^^^^^^^ 
[...]
Sist endret av 0xFF; 7. november 2017 kl. 00:24.
0xFF: Jeg forsto egentlig at dette er gatewayen, men det som er min refleksjon er at siden gatewayen på coax-nettet mitt hjemme er en lokal IP, så maskeres MAC-adressen til de virtuelle interfacesene eller noe sånt, på grunn av det rare oppsettet, og derfor fungerer det her, men ikke der det er fiber, fordi MAC-adressen ikke maskeres. Vet ikke jeg nei, har ikke snøring på hvordan CD har satt opp nettet, og ser heller ingen logisk årsak til at det skal fungere her og ikke der.. Veldig rart

Sjekket forresten route -n, og nei, jeg ser ikke den adressen. Jeg ser min offentlige IP-adresse, men med .1 på slutten istedenfor.

Nå har jeg prøvd å kjøre en MAC-adresse generator slik at det ser ut som at de virtuelle interfacesene er Cisco-utstyr. Negativt resultat, ingen forskjell.

Ringte Canal Digital og Telenoreksperten, begge deler.
Telenoreksperten: "Årsaken til dette er at det er begrensing på 2 IP-adresser fra fiberboksen."
Jeg: "Så det betyr at hvis jeg kun henter 2 IP-adresser, vil det fungere?"
Telenoreksperten: "Ja."
Jeg: "Så hvorfor får jeg i det hele tatt tildelt opptil 4 IP-adresser da?"
Da ble linjen brutt.

Jeg prøvde så å kun ha ett virtuelt interface i tillegg til det fysiske, slik at jeg altså kun hentet frem 2 IP-adresser fra fiberboksen. Funka det? NEI.
Sist endret av Rusmisbrukeren; 7. november 2017 kl. 11:49. Grunn: Automatisk sammenslåing med etterfølgende innlegg.