Prezentare
Această problemă ar putea fi rezolvată prin utilizarea spațiilor de nume de rețea, împărțind astfel un singur sistem Pi în routere X care fac NAT. Asta ar trebui făcut. Din păcate, nu știu cum să scriu un răspuns care nu ar trebui să includă doar modul de mutare a interfețelor Wifi într-un spațiu de nume de rețea nou (necesită drivere compatibile și iw phy phyX set netns... în loc de set link ip wlanX ... netns ...) dar si mai ales asociate acestora wpa_supplicant și demonii client DHCP cu modificări corespunzătoare de integrare a sistemului. Acest lucru necesită cunoștințe bune despre modul în care sistemul specific este configurat cu wireless și DHCP.
În schimb, acest răspuns evită utilizarea spațiilor de nume de rețea și evită nevoia de a reconfigura gestionarea wpa_supplicant și clientul DHCP: folosește rutarea politicilor.
Implicarea mărcilor în rutarea politicii este inevitabil pentru acest caz în care stiva de rutare va vedea doar portul de destinație 443, mai degrabă decât 4431/4432 (DNAT l-a schimbat deja înainte). Marks vor fi, de asemenea, utilizatorului pentru a seta zone de conntrack (răspuns) pentru a fi sigur că se ocupă de cazul în care mai multe camere atribuie aceeași adresă IP interfeței gazdă potrivite.
Redirecționare inversă strictă a căii (SRPF) va trebui să fie relaxat la RPF liber în cazul în care Strict a fost setat în mod implicit, deoarece manipularea ARP nu va primi mărcile și poate rămâne blocată.
Deoarece camerele ar putea să nu fi setat ruta implicită către client, dar ar putea avea doar o rută LAN, se va face și NAT dublu (sursă și destinație).
Înființat
Deoarece OP nu a furnizat niciunul eth0 setare, nu e niciunul aici. Răspunsul încearcă să nu depindă prea mult de asta, dar OP ar trebui să-l adapteze dacă va fi nevoie (mai ales dacă cele 7 interfețe wireless nu vor avea toate numele începând cu wlx).
Să ajustăm obiectivul:
192.168.42.0/24 reprezintă mai multe rețele IP suprapuse la care nu trebuie accesate direct pentru a proteja clienții externi de toată complexitatea posibilă de rutare.
Deci adresa 192.168.42.250 nu va fi folosită. Adresa vizibilă a lui Pi 192.168.0.205 va fi utilizată de la clienții la distanță.
Orice acces HTTPS va primi un certificat prost. Tratează-te cu asta: ofer un răspuns bazat pe modificarea setărilor de rețea, dar nu va include configurarea unui proxy invers pentru a ascunde problema certificatului. Adăugarea unui astfel de proxy invers necesită, de asemenea, mai multe modificări ale rețelei (adăugat ca opțiune la sfârșit). Testele pot fi făcute de la un client (dar nu de la RPi) cu:
curl --nesigur https://192.168.0.205:4431/
curl --nesigur https://192.168.0.205:4432/
De asemenea, pentru a arăta câteva exemple mai jos, am luat cazul cu ambele camere având atribuită aceeași adresă IP gazdei, astfel încât să apară pe două interfețe, pentru a ridica ștacheta. Nu contează. Cele mai multe dintre aceste setări trebuie făcute după ce toate conexiunile wireless sunt efectuate, mai degrabă decât înainte. Nu mă voi ocupa de cum să integrez acest lucru cu sistemul de operare Linux specific care îl gestionează.
Toate comenzile ar trebui să fie executate ca root.
Exemplele se bazează pe:
# traseu ip
implicit prin 192.168.0.1 dev wlan0
192.168.0.0/24 dev wlan0 proto kernel scope link src 192.168.0.205
192.168.42.0/24 dev wlxb8b7f16a0602 proto kernel scope link src 192.168.42.10 metric 600
192.168.42.0/24 dev wlxb8b7f16a04cd proto kernel scope link src 192.168.42.10 metric 600
Reguli de rutare pentru a selecta tabele de rutare suplimentare care vor izola dublarea fiecărei rețele LAN a camerei de cealaltă LAN a camerei:
regulă ip adăugați fwmark 1 căutare 4431
regulă ip adăugați fwmark 2 căutare 4432
IP route add 192.168.42.0/24 dev wlxb8b7f16a0602 tabelul 4431
IP route add 192.168.42.0/24 dev wlxb8b7f16a04cd tabelul 4432
Acest lucru face ca rutarea să funcționeze de la client la camere (dacă RPi nu are o rută implicită, exemplele de mai jos folosind 192.0.2.2 pentru a testa rutele ar putea folosi 192.168.0.101):
# ip route obține nota 2 de la 192.0.2.2 iif wlan0 192.168.42.1
192.168.42.1 din 192.0.2.2 dev wlxb8b7f16a04cd tabel 4432 marca 2
cache iif wlan0
dar tot nu pentru răspunsuri dacă SRPF este activat:
# ip route obține nota 2 de la 192.168.42.1 iif wlxb8b7f16a04cd 192.0.2.2
Răspunsuri RTNETLINK: Legătură între dispozitive nevalidă
Deci un steag aproape nedocumentat ar trebui setat pe interfețele camerei:
sysctl -w net.ipv4.conf.wlxb8b7f16a0602.src_valid_mark=1
sysctl -w net.ipv4.conf.wlxb8b7f16a04cd.src_valid_mark=1
pentru a obține acum:
# ip route obține marcajul 2 de la 192.168.42.1 iif wlxb8b7f16a04cd 192.0.2.2
192.0.2.2 de la 192.168.42.1 prin 192.168.0.1 dev wlan0 mark 2
cache iif wlxb8b7f16a04cd
Dar de fapt, oricum ARP (de la cameră la gazdă) este încă întrerupt atunci când SRPF este setat, deoarece ARP nu primește mărcile iptables.
Așa că folosește doar RPF liber (rp_filter=2) în schimb (și apoi setarea pentru src_valid_mark de mai sus nu mai este nevoie) pentru a o rezolva. Acest lucru funcționează indiferent dacă RPF a fost dezactivat sau setat strict înainte:
sysctl -w net.ipv4.conf.wlxb8b7f16a0602.rp_filter=2
sysctl -w net.ipv4.conf.wlxb8b7f16a04cd.rp_filter=2
Adăugați marcaje de setare a regulilor iptables pentru a finaliza partea de rutare, precum și pentru a rezolva mai târziu adresele conflictuale în NAT, setând selectorul zonei de răspuns.
iptables -t raw -A PRERUTARE ! -i wlx+ -p tcp --dport 4431 -j MARK --set-mark 1
iptables -t raw -A PREROUTING -i wlxb8b7f16a0602 -j MARK --set-mark 1
iptables -t raw -A PREROUTING -m mark --mark 1 -j CT --zone-reply 1
iptables -t raw -A PRERUTARE ! -i wlx+ -p tcp --dport 4432 -j MARK --set-mark 2
iptables -t raw -A PREROUTING -i wlxb8b7f16a04cd -j MARK --set-mark 2
iptables -t raw -A PREROUTING -m mark --mark 2 -j CT --zone-reply 2
Adăugați acele reguli la NAT la IP-ul și portul țintă (care sunt întotdeauna aceleași). Interfața corectă va fi apoi aleasă de stiva de rutare datorită setărilor anterioare:
iptables -t nat -A PRERUUTARE ! -i wlx+ -p tcp -m marca ! --mark 0 -j DNAT --to-destination 192.168.42.1:443
iptables -t nat -A POSTROUTING -o wlx+ -j MASQUERADE
Dacă se adaugă o a treia interfață numită wlx3, iată pașii. Poate fi generalizat în același mod pentru mai multe:
Adăugați o nouă regulă IP selectată cu un nou marcaj (3) care va folosi o nouă tabelă de rutare (4433):
regulă ip adăugați fwmark 3 căutare 4433
Adăugați noul tabel de rutare care se potrivește cu intrarea sa mai mult sau mai puțin duplicată din ruta LAN a tabelului principal pentru noua interfață:
IP route add 192.168.42.0/24 dev wlx3 tabel 4433
Slăbiți RPF pe această interfață dacă setările implicite ale sistemului de operare au fost SRPF (după cum s-a spus src_valid_mark nu este necesar până la urmă):
sysctl -w net.ipv4.conf.wlx3.rp_filter=2
Alegeți un port nou (4433) și adăugați 3 noi raw/PREROUTING iptables reguli care includ noul port, noul marcaj și noua interfață:
iptables -t raw -A PRERUTARE ! -i wlx+ -p tcp --dport 4433 -j MARK --set-mark 3
iptables -t raw -A PREROUTING -i wlx3 -j MARK --set-mark 3
iptables -t raw -A PREROUTING -m mark --mark 3 -j CT --zone-reply 3
(Dacă numele noii interfețe nu începe cu wlx adăuga nou nat reglementează în consecință.)
Iată un exemplu de contratrack gestionarea atunci când un client se conectează de două ori, chiar și folosind același port sursă, la cele două porturi, în timp ce RPi a primit aceeași adresă IP atribuită celor două interfețe wireless wlx. The contratrack zona este inclusă în selecția fluxului și permite ca NAT să fie gestionat corect, chiar dacă o parte a fluxurilor vede exact aceleași adrese și porturi:
# conttrack -E
[NOU] tcp 6 120 SYN_SENT src=192.168.0.101 dst=192.168.0.205 sport=6666 dport=4431 [NERĂSPUNS] src=192.168.42.1 dst=192.168.0.205 sport=192.160.42.168=192.16168.
[UPDATE] tcp 6 60 SYN_RECV src=192.168.0.101 dst=192.168.0.205 sport=6666 dport=4431 src=192.168.42.1 dst=192.168.0.101 dst=192.168.0.205 sport=6666 dport=4431 src=192.168.42.1 dst=192.168.0.101
[UPDATE] tcp 6 432000 ESTABLISHED src=192.168.0.101 dst=192.168.0.205 sport=6666 dport=4431 src=192.168.42.1 dst=192.168.0.101 dst=192.168.0.205 sport=re64463 dst=6666 dport=4431 src=192.168.42.1
[NOU] tcp 6 120 SYN_SENT src=192.168.0.101 dst=192.168.0.205 sport=6666 dport=4432 [NERĂSPUNS] src=192.168.42.1 dst=192.168.0.205 sport=192.160.42.168=192.16068.
[UPDATE] tcp 6 60 SYN_RECV src=192.168.0.101 dst=192.168.0.205 sport=6666 dport=4432 src=192.168.42.1 dst=192.168.0.101 dst=192.168.0.205 sport=6666 dport=4432 src=192.168.42.1 dst=192.168.0.101 dst=192.168.0.205 sport=668.0.205
[UPDATE] tcp 6 432000 ESTABLISHED src=192.168.0.101 dst=192.168.0.205 sport=6666 dport=4432 src=192.168.42.1 dst=192.168.0.101 dst=192.168.0.205 sport=re64463 dst=6666 dport=4432 src=192.168.42.1
Diverse
diverse 1
Pentru ca o cameră să poată trimite ping gazdei sau să primească erori ICMP de la gazdă, trebuie adăugată această setare (globală):
sysctl -w net.ipv4.fwmark_reflect=1
altfel răspunsul ICMP nu urmează politica de rutare. O altă modalitate mai bună este utilizarea CONNMARK/connmark, dar ar face răspunsul inutil mai complex.
Diverse 2
Rezultatul de lucru nu poate fi testat corect de la RPi în sine, ci doar de la un client pe LAN (sau pe Internet cu suport de la routerul RPi). Setările sunt specifice cazului de rutare.
Opțional, pentru ca gazda să poată funcționa (și să permită instalarea unui proxy invers), pot fi adăugate aceste setări suplimentare:
Selectați interfața potrivită chiar înainte de a se produce NAT (necesită nucleu >= 4.17), altfel socketul va alege adresa sursă greșită (a unei alte interfețe) mai târziu:
regulă ip add iif lo iproto tcp dport 4431 căutare 4431
regulă ip add iif lo iproto tcp dport 4432 căutare 4432
Destinația trebuie să fie marcată DNA în nat/OUTPUT. Nu este nevoie de numele exact wlx aici, ruta de ieșire corectă a fost deja selectată de stiva de rutare cu noile reguli de rutare (răspunsul necesită încă o parte din regulile iptables raw/PREROUTING din răspunsul principal). Și a contratrack zona de răspuns este, de asemenea, necesară în raw/OUTPUT pentru a gestiona cazurile de ciocnire rare.
iptables -t raw -A OUTPUT -o wlx+ -p tcp --dport 4431 -j MARK --set-mark 1
iptables -t raw -A OUTPUT -m mark --mark 1 -j CT --zone-reply 1
iptables -t raw -A OUTPUT -o wlx+ -p tcp --dport 4432 -j MARK --set-mark 2
iptables -t raw -A OUTPUT -m mark --mark 2 -j CT --zone-reply 2
iptables -t nat -A OUTPUT -p tcp -m mark ! --mark 0 -j DNAT --to-destination :443
Testele în acest caz ar trebui făcute din RPi cu:
curl --nesigur https://192.168.42.1:4431/
curl --nesigur https://192.168.42.1:4432/
diverse 3
Setările în diverse 2 dacă este adaptat pentru gestionarea locală a UDP, pentru un caz diferit de OP, probabil că nu ar fi suficient pentru unele cazuri de colț: UDP are întotdeauna nevoie de suport din partea aplicației locale atunci când se află într-un mediu multi-homed.
