Aşağıdaki sorun, sorun yaşadığım daha büyük çözümün sadece bir parçası. Diğer tüm öğeler şu ana kadar çalışıyor gibi görünüyor, bu yüzden sorun yaşadığım çok küçük bir parçayı tarif etmeye çalışacağım.
Tun0 (tünel arabirimi) ve eth0 (cadı internete varsayılan ağ geçidim ) olan bir linux makinem var .
Hedef: Amacım tun0'dan gelen paketleri almak ve bunları varsayılan ağ geçidine iletmektir. Yani aslında oldukça basit NAT durumda, ben fiziksel arayüzü taklit tun0 ile internet "paylaşmak" istiyorum.
Tun kullanılarak oluşturuldu
sudo openvpn --mktun --dev tun0 --user USER
sudo ip addr add 10.2.0.1/24 dev tun0
sudo ip link set tun0 up
Bu yüzden o kadar var ve çalışıyor, ben ping vb. Ayrıca, bu TUN cihazına bağlanır, okuyabilir ve yazabilir C ++ uygulaması var. (fti: İşte takip ettiğim bir öğretici: http://backreference.org/2010/03/26/tuntap-interface-tutorial/ )
8.8.8.8 için yapılan bazı doğru ICMP (ping) isteğini C ++ bayt dizisine döktüm. Şimdi programımı kullanarak tun0 cihazına yazıyorum. ICMP isteği var
- source (10.2.0.10) - böylece çekirdek geri dönüş yolunu biliyor (aynı alt ağ)
- destination (8.8.8.8) - Google'ın DNS'si
- Sağlama toplamı vb. (Wireshark / TShark'ta tun0'da doğru görünür)
Sonra, aşağıdaki yolları var:
iptables -F # flush
iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE
iptables --append FORWARD --in-interface tun0 -j ACCEPT
Ve burada takılıp kaldım :( Paket varsayılan gw'ye yönlendirilmez (tshark sadece tun0'da aldığı gibi doğru olduğunu tahmin eder)
Ne kayıp? Belki bazı alternatif yaklaşımlar (ancak tun cihazı kullanılarak yapılması gerekiyor ve buna r / w yapabilmeliyim). İlave bilgi:
- yönlendirme etkin (/ proc / sys / net / ipv4 / ip_forward)
- 8.8.8.8'e eth0 aracılığıyla ulaşılabilir (yerelden)
- varsayılan ağ geçidi doğrudur (ISS'den eth0 üzerinden)
- rp_tables (echo 0> / proc / sys / net / ipv4 / conf / eth5 / rp_filter) kapatmayı denedim
- Ve bircok digerleri...
Herhangi bir ipucu için şimdiden teşekkürler!