Lapsio's questions

Estou usando comunicação de rádio entre o ponto de acesso e a estação linux. Quando a máquina envia apenas pacotes, a qualidade da conexão é boa. O mesmo pode ser dito sobre a situação em que a máquina baixa apenas pacotes (a maioria dos pacotes vai em uma direção). No entanto, infelizmente, quando a comunicação está mais próxima de 50/50, o link se torna bastante instável e a latência enlouquece. Eu poderia usar dois rádios usando frequências separadas para uplink e downlink para evitar interferência (full duplex), porém é possível configurar o Linux para usá-lo?

Estou falando de configuração com IP único onde os pacotes são enviados por uma interface e recebidos por outra. Tanto o ap quanto a estação são baseados em Linux.

Eu habilitei issue_discardsem lvm.confarquivo na máquina com ssd e gostaria de executar blkdiscardem um dos volumes lógicos. Posso fazer isso sem reiniciar a máquina? Posso desmontar o volume físico junto com todos os volumes lógicos armazenados neste ssd específico, mas prefiro evitar a reinicialização do sistema.

Por curiosidade, estou lendo alguns tutoriais sobre proxies TOR transparentes, pois é um tópico bastante interessante do ponto de vista da rede. Ao contrário dos gateways VPN que usam apenas tun/ tapinterfaces e são totalmente claros para mim, o proxy TOR usa uma única porta. Todos os tutoriais repetem a linha mágica:

iptables -t nat -A PREROUTING -i eth0 -p tcp --syn -j REDIRECT --to-ports 9040

onde eth0é a interface de entrada (LAN) e 9040é alguma porta TOR. O problema é que não entendo completamente por que tal coisa faz sentido do ponto de vista da rede.

De acordo com o meu entendimento de redirect/ dst-natchains e como parece funcionar em roteadores físicos, dst-nata cadeia toma dst-porte dst-addr ANTES que a decisão de roteamento seja tomada e os altere para outra coisa. Então por exemplo:

• antes dst-nat:192.168.1.2:46364 -> 88.88.88.88:80
• depois dst-nat:192.168.1.2:46364 -> 99.99.99.99:8080

E 99.99.99.99:8080é o que outras cadeias na faixa de fluxo de pacotes IP veem (por exemplo filter, tabela) e é assim que o pacote fica a partir de agora após deixar o dispositivo, por exemplo.

Agora, muitas pessoas na Internet (incluindo neste stackexchange) alegaram que redirecté basicamente o mesmo que dst-natdefinir dst-addro endereço local da interface. Diante disso, esta regra:

iptables -t nat -A PREROUTING -i eth0 -p tcp --syn -j REDIRECT --to-ports 9040

claramente não faz sentido. Se fosse assim que funcionasse, o TOR obteria todos os pacotes com destino 127.0.0.1:9040. Para aplicativos típicos em que o aplicativo pega o pacote e responde a ele de alguma forma (por exemplo, servidores da Web), faz todo o sentido porque, afinal, esse processo do servidor é o destino final do pacote de qualquer maneira, portanto, tudo bem que o endereço de destino seja localhost. Mas o roteador TOR é bem ... um roteador, então ele precisa saber o destino original do pacote. Estou esquecendo de algo? Não DNATafeta o que os aplicativos locais recebem? Ou é um comportamento específico da REDIRECTdiretiva?