路由转发实操

0x01 实操原因

玩htb的时候，kali实在不能再多进程啦，开个bp都卡死，之前我不是想着由物理机去开burpsuite，解放kali嘛，但是失败了，当时burp是抓到了虚拟机里访问目标web的包，但是它作为一个代理，源ip(burp)与目的ip(htb)不在同网段，遗憾放弃；但现在不一样了，我是真的花时间去想这个东西，还真让我找到了

0x02 过程

系统	ip
windows	192.168.1.142
kali	(NAT模式)192.168.241.3
	(openvpn)10.10.16.18
htb	10.10.11.6

三个机子，主机为A，虚拟机kali为B(一定是NAT模式)，hackthebox为C

我可以直接给物理机下一个openvpn，但我懒

已知B通过openvpn能访问C；而我A和B属于另一网段，可互相访问；现在B容易卡死，因为主机太垃圾，虚拟机空间不够，所以我想尝试A通过B访问C，这种思路分析一下，那就是个代理技术，B作为代理服务器，感觉有搞头嘞

但是貌似有更直接的方法，即路由转发，补充一点，这里还是涉及到必要的NAT转换

window下：
route add 10.0.0.0 mask 255.0.0.0 192.168.241.3 #流向C的流量，发往kali
#其实是下面这种
#第一条规则告诉主机A，当它试图访问 10.10.11.249 时，数据包应该通过路由到 10.10.16.9(B使用openvpn时分配的ip)。
route add 10.10.16.9 mask 255.255.255.255 192.168.241.3(B的ip)
#第二条规则告诉主机A，当它试图访问 10.10.16.9 时，数据包应该通过路由到 192.168.241.3。
route add 10.10.11.249 mask 255.255.255.255 10.10.16.9

kali下：
sudo sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o <OpenVPN接口> -j MASQUERADE #接口比如tun0

#下面这几个缺一不可
#将从物理机A到虚拟机B (Kali) 的流量的源IP地址修改为虚拟机B (Kali) 的IP地址，并且确保相关的转发规则
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

#iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i tun0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT

iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT

#iptables -t nat -L -n -v #查看配置的

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

• -t nat: 指定规则表为 “nat” 表，即网络地址转换表。

• -A POSTROUTING: 在 “nat” 表的 POSTROUTING 链中追加规则，即对于从本地网络流出的数据包进行处理。

• -o tun0: 指定出口接口为 tun0，即数据包将通过这个接口离开本地网络。

• -j MASQUERADE: 使用 MASQUERADE 目标，将数据包的源地址替换为本地网络接口的地址，使其看起来像是从主机直接流出的

  为通过 tun0 接口流出的数据包进行地址伪装，使得它们看起来像是直接从主机发出的。这通常用于隐藏内部网络结构

iptables -A FORWARD -i tun0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT

-A FORWARD: 在 “filter” 表的 FORWARD 链中追加规则，即用于处理转发的数据包

-i tun0 -o eth0: 数据包从 tun0 接口进入，经过 eth0 接口流出。

-m state –state RELATED,ESTABLISHED: 匹配已建立连接或与已建立连接相关的数据包。

-j ACCEPT: 允许匹配的数据包通过

#↑允许已建立连接或相关的数据包在 tun0 和 eth0 之间进行转发

iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT

• -A FORWARD: 在 “filter” 表的 FORWARD 链中追加规则。
• -i eth0 -o tun0: 数据包从 eth0 接口进入，经过 tun0 接口流出。
• -j ACCEPT: 允许所有匹配的数据包通过。

这条规则的作用是允许所有从 eth0 到 tun0 的数据包进行转发。

可行，这种方式解决了虚拟机内存不够的问题，进程多了容易卡死，这个应该就可以用我物理机的burp去抓包了

只需要在虚拟机里设置一下http，ip为虚拟机网关ip，而物理机的bp(点击选择特定地址时，会有选项的)监听即可

总结一下，windows机去添加两条路由，告诉数据包应该怎么走；kali做ip转发，以及源ip转换

burp抓包的话，监听地址为vmet8的网关，虚拟机去firefox设置下同名代理，一致即可

另附bp白名单设置：

1.Target->Scope

2.proxy勾选对应的正则(is in target scope)才会生效

参考来源：chatgpt 3.5 (啧，折腾好久)

补充

后面我又遇到同样的需求，重复操作时，不能达到这种目的

那我觉得有必要去深究一下iptables了

环境与目的

系统	ip
windows	192.168.1.142
kali	(桥接)192.168.1.117
	(openvpn)10.10.16.18
htb	10.10.11.6

通信情况：win与kali同网段互通，kali通过openvpn与htb互通

目的：win能ping通htb

思路分析：

目前主机与kali的eth0在同一网段；如果想要ping通kali的tun0网段，只需要在主机路由到tun0即可；关键是ping通htb；

那就是说通过改源地址和目的地址的方式。

但这里已经看出来了，kali和主机是桥接模式，不是NAT模式；貌似只能看单纯的流量转发

而且桥接模式下，kali必须做个代理，不然bp抓不到的，还是用NAT模式吧，一般是监听出口网卡如vmet8

桥接模式补充

2024/4/30

那么桥接模式意味着，虚拟机和主机是同一局域网下独立的两台机子，无非就是主机A去获取B的流量

yakit的远程劫持，就是解决抓桥接模式虚拟机流量的问题

远程模式介绍 https://yaklang.io/products/connection/

这里适用于虚拟机适用了openvpn连接htb的情况，只需要虚拟机搭建gRPC服务器，主机用yakit工具进行连接就可以实现抓包

RPC都熟悉，即远程过程调用；这种和一般的内网穿透工具效果差不多

只不过协议上内网工具有的是TCP、UDP等、而gRPC是HTTP/2作为底层通信协议；

而且gRPC部署有要求(支持加密)，不像那些工具即传即用；

gRPC这种主要是用于分布式的需求，而内网工具一般用于绕过网络限制

我只能理解为建立了一种隧道通信方式

服务器会打开本地端口 8087

那么kali和主机走的是eth0网卡，抓个包，emmm，tlsv1.2协议，那我只好把grpc的tls关掉，不然还要解密

yak grpc --host 0.0.0.0 --port 8087
#否则（--secret 1234 --tls）

建立完后

主机ip	192.168.1.103
kali ip	192.168.1.104

主机的端口情况

TCP    192.168.1.103:23188    192.168.1.104:8087     ESTABLISHED     24176
这个就是grpc客户端和服务器之间通信，它们不停地互通

先在kali的浏览器进行一次登录，主机这边获得的数据包就两个

对于htb与kali，很简单，无非是2次的请求与响应

对于kali的eth0，或者主机的wlan讲，都是kali先发过来的一个请求

红色的是kali流量(以源ip为准)；蓝色的是主机流量

wireshark…说实话我有点看不懂这个tcp追踪流

从观感上来讲，kali的流量要多一些，主机给的比较被动

当kali给了一大堆流量后，主机才回复很少一段；

这里从全局看一下流量走向，我姑且认为是这样的

kali中浏览器访问(tun0网卡)->kali的eth0网卡8087端口->主机的23188端口

嗯没了，其实这里面还牵扯到浏览器的8080代理，以及yakit工具的8080劫持端口，这样设置了才会有效，但是让我疑惑的就是，没有看到这里的流量

端口开启倒是知道，kali有8080端口，是因为设置了代理服务器，而yakit工具虽然劫持8080端口，但是没在代理服务器设置

噢，查看kali的gRPC服务器的消息可知，当主机的yakit设置的时候，就已经指明了一个代理服务器了

[INFO] 2024-04-30 15:30:09 [grpc_mitm:1696] start serve mitm server for 127.0.0.1:8098
[INFO] 2024-04-30 15:30:09 [mitm:343] start to server mitm server: tcp://127.0.0.1:8098

本来是8080，这个无所谓，也就是我主机设置的127.0.0.1:8098，实际上是针对于kali的127.0.0.1:8098

那么本地的8098->eth0的8087，表面上看是这样的，实际上我也不确定，这个具体原理我就不深究了

主要是yakit的远程劫持模式对桥接模式流量的抓包提供了便利

iptables

NAT表

链	作用
PREROUTING	传入时，修改数据包的目的ip地址
POSTROUTING	传出时，修改数据包的源ip地址
OUTPUT	定义对本地产生的数据包的目的NAT规则

————————2024/3/22补充——————————

引入

根据蛋老师的讲解，以linux服务器为例，分为三部分

硬件(网卡) ->内核空间(linux内核) ->用户空间(网络应用)

在硬件与软件之间的流量，想要进行干预/处理，可以使用linux内核的netfilter机制，用iptables命令操纵即可

详解

iptables，四表五链

四表：filter、nat、(不常见的三表：mangle、raw、security)，每个表管理的链又不同

五链：PREROUTING、INPUT、OUTPUT、FORWARD、POSTROUTING

这里为了讲清五链的位置，蛋老师讲linux系统作为路由器讲解

网卡	—>(prerouting)	linux路由	—>(input)	网络应用
		↑(forward)
	<—(postrouting)		<—(output)

这里清晰地指明了，流量一到达系统就由PREROUTING链负责；数据包的目标是本机，就走INPUT链；从本机出去走OUT链；经过本机路由，则FORWARD链；离开本机，走POSTROUTING链

使用filter表，只需要管理input、forward、output链即可，负责数据包的目标为本机、转发或其他地址

语法格式：iptables 表 链 规则

iptables --table filter --list

#这个是拒绝源地址为xip的访问
iptables --table filter --append INPUT --source 192.168.1.x --jump REJECT

保存规则

sudo iptables-save
#或，保存为文件
sudo iptables-save > /etc/iptables/rules.v4
iptables-restore < /etc/iptables/rules.v4

参考：

一口linux http://t.csdnimg.cn/rnmaB

B站 技术蛋老师