înregistrare Logare
Puncte:0
t-r0d avatar Server

De ce pachetele netcat sunt redirecționate de regulile iptables, dar nu de o solicitare curl?

drapel in
t-r0d

Încerc să direcționez tot traficul printr-un tunel SSH/proxy SOCKS5. Am câteva reguli de tabele IP configurate pentru a redirecționa (aproape) tot traficul către un program bazat pe socket care apoi negociază și redirecționează traficul către proxy-ul SOCKS5. Ceea ce constat este că nu tot traficul meu este redirecționat corect și bănuiesc că este iptables reguli care nu funcționează. Ar fi cineva dispus să-mi împrumute o a doua pereche de ochi?

De exemplu, pot alerga nc 8.8.8.8 80 2>&1 și văd în programul meu bazat pe socket că redirecționarea are loc. Dar când eu curl google.com, primesc o eroare de rezoluție: curl: (6) Nu s-a putut rezolva gazda: google.com. Nu există jurnale în programul meu bazat pe socket care să arate că a fost încercată orice redirecționare.

Am programul bazat pe socket care ascult la 0.0.0.0:9900 iar proxy-ul SOCKS5 este inițiat pe portul 9901, de exemplu. Rulez toate acestea într-un container Docker, în cazul în care contează (dar nu cred că ar trebui să conteze prea mult...).

Inițiez proxy-ul SOCKS5 astfel:

#!/usr/bin/env bash

ssh -D 127.0.0.1:9901 -N [email protected]

Aici sunt iptables regulile pe care le folosesc:

#!/usr/bin/env bash

# Creați un lanț nou în tabelul NAT.
iptables -t nat --new-chain CUSTOM

# Creați o regulă pentru a lăsa pachetele destinate localhost în pace.
iptables -t nat --append CUSTOM --destination 127.0.0.0/8 --jump RETURN

# Creați o regulă pentru a părăsi tunelul pe care îl vom crea singuri.
# 192.168.0.25 este IP-ul static al mașinii care rulează serverul SOCKS5.
iptables -t nat --append CUSTOM --destination 192.168.0.25 --protocol tcp --destination-port 22 --jump RETURN

# Creați o regulă pentru redirecționarea întregului trafic TCP prin tunelul SSH.
iptables -t nat --append CUSTOM --protocol tcp --jump LOG --log-level info --log-prefix='[iptables] '
iptables -t nat --append CUSTOM --protocol tcp --jump REDIRECT --la-porturi 9900

# Conectați lanțurile OUTPUT și PREROUTING ale tabelului NAT la lanțul nostru personalizat definit de utilizator.
iptables -t nat -I IEȘIRE 1 --jump CUSTOM
iptables -t nat -I PREROUTING 1 --jump CUSTOM

Și aici este rezultatul complet al iptables -t nat -L -v:

PRERUUTARE în lanț (politica ACCEPTĂ 165 pachete, 21537 octeți)
 pkts bytes target prot opt ​​in out source destination         
  165 21537 CUSTOM toate -- oriunde oriunde oriunde            
 5129 389K DOCKER toate -- oriunde oriunde oriunde ADDRTYPE se potrivește cu dst-type LOCAL
 6987 1026K delegate_prerouting all -- oricare oriunde oriunde            

INTRARE în lanț (politica ACCEPTĂ 114 pachete, 8854 octeți)
 pkts bytes target prot opt ​​in out source destination         

IEȘIRE în lanț (politica ACCEPTĂ 40 de pachete, 2369 de octeți)
 pkts bytes target prot opt ​​in out source destination         
   40 2369 CUSTOM toate -- oriunde oriunde oriunde            
    0 0 DOCKER all -- oricare oriunde oriunde !127.0.0.0/8 ADDRTYPE se potrivește cu dst-type LOCAL

POSTROUTING în lanț (politica ACCEPTĂ 39 de pachete, 2301 de octeți)
 pkts bytes target prot opt ​​in out source destination         
   72 9027 MASQUERADE toate -- orice !docker0 172.17.0.0/16 oriunde            
 1614 99565 delegate_postrouting all -- oricare oriunde oriunde            

Lanț DOCKER (2 referințe)
 pkts bytes target prot opt ​​in out source destination         
    0 0 RETURN all -- docker0 oriunde oriunde            

Lanț CUSTOM (2 referințe)
 pkts bytes target prot opt ​​in out source destination         
   39 2301 RETURN all -- oricare oriunde oriunde 127.0.0.0/8         
    0 0 RETURN tcp -- orice oriunde oriunde 192.168.0.25 tcp dpt:ssh
    0 0 LOG tcp -- oriunde oriunde oriunde prefixul informațiilor la nivel de LOG „[iptables]”
    0 0 REDIRECT tcp -- oriunde oriunde oriunde porturi redir 9900

Lanț MINIUPNPD (2 referințe)
 pkts bytes target prot opt ​​in out source destination         

Chain delegate_postrouting (1 referințe)
 pkts bytes target prot opt ​​in out source destination         
 1614 99565 postrouting_rule all -- orice oriunde oriunde oriunde /* lanț de utilizatori pentru postrouting */
    0 0 zone_lan_postrouting all -- orice br-lan oriunde oriunde            
    0 0 zone_wifi_postrouting all -- orice br-wifi oriunde oriunde            
   55 5757 zone_wan_postrouting all -- orice eth0 oriunde oriunde            

Chain delegate_prerouting (1 referințe)
 pkts bytes target prot opt ​​in out source destination         
 6987 1026K prerouting_rule all -- oriunde oriunde oriunde /* lanț de utilizatori pentru preroutare */
 4545 342K zone_lan_prerouting all -- br-lan oriunde oriunde            
    1 32 zone_wifi_prerouting all -- br-wifi oriunde oriunde            
 2441 684K zone_wan_prerouting all -- eth0 oriunde oriunde            

Chain postrouting_lan_rule (1 referințe)
 pkts bytes target prot opt ​​in out source destination         

Chain postrouting_rule (1 referințe)
 pkts bytes target prot opt ​​in out source destination         

Chain postrouting_wan_rule (1 referințe)
 pkts bytes target prot opt ​​in out source destination         

Chain postrouting_wifi_rule (1 referințe)
 pkts bytes target prot opt ​​in out source destination         

Chain prerouting_lan_rule (1 referințe)
 pkts bytes target prot opt ​​in out source destination         

Chain prerouting_rule (1 referințe)
 pkts bytes target prot opt ​​in out source destination         

Chain prerouting_wan_rule (1 referințe)
 pkts bytes target prot opt ​​in out source destination         

Chain prerouting_wifi_rule (1 referințe)
 pkts bytes target prot opt ​​in out source destination         

Lanț zone_lan_postrouting (1 referințe)
 pkts bytes target prot opt ​​in out source destination         
    0 0 postrouting_lan_rule all -- orice oriunde oriunde oriunde /* lanț de utilizatori pentru postrouting */

Lanț zone_lan_prerouting (1 referințe)
 pkts bytes target prot opt ​​in out source destination         
 4545 342K prerouting_lan_rule all -- oriunde oriunde oriunde /* lanț de utilizatori pentru preroutare */

Lanț zone_wan_postrouting (1 referințe)
 pkts bytes target prot opt ​​in out source destination         
   55 5757 postrouting_wan_rule all -- orice oriunde oriunde oriunde /* lanț de utilizatori pentru postrouting */
   55 5757 MASQUERADE toate -- oriunde oriunde oriunde            

Lanț zone_wan_prerouting (1 referințe)
 pkts bytes target prot opt ​​in out source destination         
 2441 684K MINIUPNPD toate -- oriunde oriunde oriunde            
 2441 684K MINIUPNPD toate -- oriunde oriunde oriunde            
 2441 684K prerouting_wan_rule all -- oriunde oriunde oriunde /* lanț de utilizatori pentru preroutare */

Chain zone_wifi_postrouting (1 referințe)
 pkts bytes target prot opt ​​in out source destination         
    0 0 postrouting_wifi_rule all -- orice oriunde oriunde oriunde /* lanț de utilizatori pentru postrouting */

Chain zone_wifi_prerouting (1 referințe)
 pkts bytes target prot opt ​​in out source destination         
    1 32 prerouting_wifi_rule all -- any anywhere anywhere /* lanț de utilizatori pentru prerouting */

Anunță-mă dacă mai sunt și alte informații pe care ar trebui să le includ și mulțumesc anticipat!

46
0 + 0
dave_thompson_085 avatar
drapel jp
dave_thompson_085
Problema nu este curl, ci DNS, care folosește UDP, nu TCP (cu excepția unor cazuri speciale care nu sunt relevante aici), și în timp ce iptables poate redirecționa UDP (cu modificările corespunzătoare), nu îl puteți trimite printr-un tunel OpenSSH. `curl http://142.250.65.206` va fi redirecționat către unul dintre sistemele (multe) Google, deși vă va oferi doar un 301 la www.google.com, care se află la _diferite_ adrese, inclusiv 142.250.251.32 -- ceea ce va da încă 301 pentru o solicitare folosind IPaddress. Cea mai mare parte a internetului depinde de DNS și încercarea de a folosi adrese „de mână” cauzează în mare parte probleme. Poate vrei un VPN.
0
Răspunde
Puncte:0
avatar Server
drapel cn
Joshua Jacobson

Bun venit la StackOverflow!

Pe baza erorii din cererea dvs. de curl, se pare că solicitarea DNS nu reușește chiar înainte de a încerca conectarea la google.com.

În sistemele POSIX, rezoluția DNS este controlată de fișierul /etc/resolv.conf. Dacă acel fișier nu conține nicio linie de server de nume, sistemul dumneavoastră nu va putea rezolva gazda. Adăugarea uneia poate fi la fel de simplă ca și adăugarea acestei linii:

server de nume 8.8.8.8

Pe sistemele Linux mai noi, rezoluția poate fi controlată de systemd-resolved și veți vedea o linie ca aceasta:

serverul de nume 127.0.0.53

În acest caz, editarea /etc/resolv.conf fișierul va fi doar o soluție temporară, deoarece systemd va suprascrie periodic fișierul. În acest caz, va trebui să editați configurația netplan în /etc/netplan/ sau dezactivați systemd-resolved.

Referinte:

0 + 0
t-r0d avatar
drapel in
t-r0d
Mulțumesc pentru intrare! Sunt de acord că DNS nu eșuează, dar sugestia dvs. nu ar duce la producerea DNS la nivelul clientului? Aș dori ca rezoluția DNS să se întâmple pe mașina de la distanță (serverul SSH).
0
Răspunde
dave_thompson_085 avatar
drapel jp
dave_thompson_085
Nu; DNS folosește UDP, pe care nu îl puteți redirecționa prin SSH.
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

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.