Puncte:0

Transformați pachetul Broadcast în pachet Unicast cu iptables și ebtables

drapel in

Mă confrunt cu această problemă de luni de zile, iar cunoștințele mele limitate de rețea nu îmi permit să progresez mai departe, așa că iată că cer un sfat.

Am un router OpenWRT cu două subrețele, 192.168.1.x și 192.168.2.x. Pe 192.168.1.x am un PC client care rulează o aplicație de care nu am surse, iar pe 192.168.2.x rulează un server cu același software. Pentru a descoperi alte servere, clientul trimite o transmisie pe rețeaua locală care evident nu va traversa subrețeaua. Dar, din moment ce știu unde este serverul, aș dori cumva să „transform” o astfel de transmisie într-un pachet UDP unicast cu adresa de destinație a acelui server.

Știu că cel mai simplu lucru de făcut ar fi să aduci atât clientul, cât și serverul pe aceeași subrețea, dar, din moment ce serverul este expus și pe Internet cu persoane diferite care se conectează cu TeamViewer, aș dori cu adevărat să-l păstrez la fel de izolat ca posibil.

Deci am venit cu

iptables -t mangle -A PREROUTING -p udp -s 192.168.1.0/24 -d 255.255.255.255 -m udp --dport 10308 -j TTL --ttl-set 128 -m comentariu --comentare „Test de difuzare a transmisiei”
iptables -t nat -A zone_lan_prerouting -p udp -s 192.168.1.0/24 -d 255.255.255.255 -m udp --dport 10308 -j DNAT --to-destination 192.168.1.0/24 -d 255.255.255.255 -m udp --dport 10308 -j DNAT --to-destination 192.168.2.3086:1030. Test transversal"

Am adaugat si un ebtables regulă pentru a suprascrie MAC-ul de destinație, astfel încât să nu fie tratat ca o difuzare:

ebtables -t nat -A PREROUTING -p ip --ip-protocol udp -d ff:ff:ff:ff:ff:ff/ff:ff:ff:ff:ff:ff --ip-destination-port 10308 - j dnat --to-destination 9c:c9:eb:15:dd:ce

În acest fel pachetul ajunge efectiv la server, care la rândul său trimite răspunsul său. Din păcate, ceva este încă în neregulă, deoarece văd aceste intrări de jurnal în fișierul IEȘIRE lanț, legat de răspunsul în sine:

IN= OUT=wlan0 Sursa MAC = 9c:c9:eb:15:dd:ce MAC dest = 50:2f:9b:2a:ba:9d proto = 0x0800 IP SRC=255.255.255.255 IP DST=192.168.1.227, IP tos=0x00, IP proto=17 SPT=10308 DPT=51719
IN= OUT=wlan0 Sursa MAC = 9c:c9:eb:15:dd:ce MAC dest = 50:2f:9b:2a:ba:9d proto = 0x0800 IP SRC=255.255.255.255 IP DST=192.168.1.227, IP tos=0x00, IP proto=17 SPT=10308 DPT=51719

m-as fi asteptat IP SRC a fi 192.168.2.36, iar pachetul trece prin REDIRECŢIONA lanț și nu cel IEȘIRE lanţ. Mă tem că asta are cumva legătură cu contratrack, care înregistrează această intrare imediat ce solicitarea este primită de la router:

[NOU] udp 17 60 src=192.168.1.227 dst=255.255.255.255 sport=65137 dport=10308 [NERĂSPUNS] src=192.168.2.36 dst=192.168.2.36 dst=192.168.168 sport=110.168.
[UPDATE] udp 17 60 src=192.168.1.227 dst=255.255.255.255 sport=65137 dport=10308 src=192.168.2.36 dst=192.168.1.255 sport=10307 d73port
[UPDATE] udp 17 60 src=192.168.1.227 dst=255.255.255.255 sport=65137 dport=10308 src=192.168.2.36 dst=192.168.1.255 sport=65137 dport=10308 src=192.168.2.36 dst=192.168.1.255.

Deci... Am vreo șansă să-mi ating cumva rezultatul?

joeqwerty avatar
drapel cv
O întrebare care poate duce la o soluție: serverul este „expus” internetului cu scopul exclusiv de a se conecta la acesta cu Teamviewer?
drapel in
Nu, este un server de jocuri disponibil public. Nu știu dacă am alegeri mai bune, dar segregarea lui în propria zonă firewall, subrețea și VLAN mi s-a părut cea mai eficientă modalitate de a obține o securitate minimă...

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.