精华内容
下载资源
问答
  • 原文地址:反向路径过滤——reverse path filter 作者:pwp_cu反向路径过滤——reverse path filter一、原理先介绍个非对称路由的概念参考《Understanding Linux Network Internals》三十章,30.2. Essential ...

    原文地址:反向路径过滤——reverse path filter 作者:pwp_cu

    反向路径过滤——reverse path filter

    一、原理
    先介绍个非对称路由的概念
    参考《Understanding Linux Network Internals》三十章,
    30.2. Essential Elements of Routing
    Symmetric routes and asymmetric routes
    Usually, the route taken from Host A to Host B is the same as the route used to get back from Host B to Host A; the route is then called symmetric . In complex setups, the route back may be different; in this case, it is asymmetric.

    关于反向路径过滤,参考《Understanding Linux Network Internals》三十一章,
    31.7. Reverse Path Filtering
    We saw what an asymmetric route is in the section "Essential Elements of Routing in Chapter 30. Asymmetric routes are not common, but may be necessary in certain cases. The default behavior of Linux is to consider asymmetric routing suspicious and therefore to drop any packet whose source IP address is not reachable through the device the packet was received from, according to the routing table.
    However, this behavior can be tuned via /proc on a per-device basis, as we will see in Chapter 36. See also the section "Input Routing" in Chapter 35.

    二、检查流程
    如果一台主机(或路由器)从接口A收到一个包,其源地址和目的地址分别是10.3.0.2和10.2.0.2,
    即, 如果启用反向路径过滤功能,它就会以为关键字去查找路由表,如果得到的输出接口不为A,则认为反向路径过滤检查失败,它就会丢弃该包。

    关于反向路径过滤,ipv4中有个参数,这个参数的说明在Documentation/networking/ip-sysctl.txt中。
    rp_filter - INTEGER
        0 - No source validation.
        1 - Strict mode as defined in RFC3704 Strict Reverse Path
            Each incoming packet is tested against the FIB and if the interface
            is not the best reverse path the packet check will fail.
            By default failed packets are discarded.
        2 - Loose mode as defined in RFC3704 Loose Reverse Path
            Each incoming packet's source address is also tested against the FIB
            and if the source address is not reachable via any interface
            the packet check will fail.

        Current recommended practice in RFC3704 is to enable strict mode
        to prevent IP spoofing from DDos attacks. If using asymmetric routing
        or other complicated routing, then loose mode is recommended.

        The max value from conf/{all,interface}/rp_filter is used
        when doing source validation on the {interface}.

        Default value is 0. Note that some distributions enable it
        in startup scripts.

    三、源代码分析
    git commit 373da0a2a33018d560afcb2c77f8842985d79594

    net/ipv4/fib_frontend.c
     192 int fib_validate_source(struct sk_buff *skb, __be32 src, __be32 dst, u8 tos,
     193                         int oif, struct net_device *dev, __be32 *spec_dst,
     194                         u32 *itag)
     195 {
                 // 是否启用反向路径过滤
     216         /* Ignore rp_filter for packets protected by IPsec. */
     217         rpf = secpath_exists(skb) ? 0 : IN_DEV_RPFILTER(in_dev);
     
                 // 检查路由表
             // 注意这里的源地址贺目的地址是反过来的,
             // 看看其他函数是如何调用fib_validate_source()就明白了。
     227         if (fib_lookup(net, &fl4, &res))
     228                 goto last_resort;

                 // 运行到这里,说明反向路由是可达的
             // 下面分成两种情况检查输出设备是否就是输入设备
     237 #ifdef CONFIG_IP_ROUTE_MULTIPATH
                 // 启用多路径时,任意一个匹配,就用它了
     238         for (ret = 0; ret < res.fi->fib_nhs; ret++) {
     239                 struct fib_nh *nh = &res.fi->fib_nh[ret];
     240
     241                 if (nh->nh_dev == dev) {
     242                         dev_match = true;
     243                         break;
     244                 }
     245         }
     246 #else
     247         if (FIB_RES_DEV(res) == dev)
     248                 dev_match = true;
     249 #endif
     250         if (dev_match) {
                  // 反向路径过滤检查成功了,返回
     251                 ret = FIB_RES_NH(res).nh_scope >= RT_SCOPE_HOST;
     252                 return ret;
     253         }
     254         if (no_addr)
     255                 goto last_resort;
                 // 运行到这里,说明反向路径检查是失败的,
             // 如果rpf为1,表示反向路径检查必须成功才能正常返回,
             // 否则只好返回错误。
     256         if (rpf == 1)
     257                 goto e_rpf;
     278 e_rpf:
     279         return -EXDEV;

    四、实例
    本网络有三台机器,R1, R2 和PC,子网掩码都是255.255.0.0。
    R2 (10.1.0.2) ---- (10.1.0.1) R1 (10.3.0.1) ---- (10.3.0.2) PC
    R2 (10.2.0.2) ---- (10.2.0.1) R1

    注意,设置R2的默认路由为10.1.0.1
    现在,从PC上能够ping通10.1.0.2,但是ping不通10.2.0.2。
    tcpdump显示,R2接到icmp request,但是不发送icmp reply。

    PC
    $ ip a
    inet 10.3.0.2/16 brd 10.3.255.255 scope global eth0
    $ ip r
    10.3.0.0/16 dev eth0  proto kernel  scope link  src 10.3.0.2
    default via 10.3.0.1 dev eth0

    R1
    $ ip a
    inet 10.1.0.1/16 brd 10.1.255.255 scope global eth1
    inet 10.2.0.1/16 brd 10.2.255.255 scope global eth2
    inet 10.3.0.1/16 brd 10.3.255.255 scope global eth3
    $ ip r
    10.1.0.0/16 dev eth1  proto kernel  scope link  src 10.1.0.1
    10.2.0.0/16 dev eth2  proto kernel  scope link  src 10.2.0.1
    10.3.0.0/16 dev eth3  proto kernel  scope link  src 10.3.0.1

    R2
    $ ip a
    inet 10.1.0.2/16 brd 10.1.255.255 scope global eth1
    inet 10.2.0.2/16 brd 10.2.255.255 scope global eth2

    $ ip r
    10.1.0.0/16 dev eth1  proto kernel  scope link  src 10.1.0.2
    10.2.0.0/16 dev eth2  proto kernel  scope link  src 10.2.0.2
    default via 10.1.0.1 dev eth1

    请问这是什么原因?
    你可以返回去细细思考5分钟......

    我的回答:
    假设R2的两个接口分别为A(10.1.0.2)、B(10.2.0.2)。
    从PC ping 10.2.0.2时,包的路径是PC-->10.3.0.1-->10.2.0.2,
    此时包的 ,
    以进行反向路径检查, 得到输出设备是A,
    因为目的地址是10.3.0.2,只能使用默认路由。A!=B,反向路径检查失败,
    丢弃该包!

    五、如何解决
    两种方法:
    1 On R2:
    ip route add 10.3.0.0/16 via 10.2.0.2
    增加一条关于10.3.0.0/16子网的路由。

    2 On R2:
    /etc/sysctl.conf
    net.ipv4.conf.default.rp_filter = 0
    禁用反向路径检查。

     

    展开全文
  • 非对称路径流量We have written a series of articles about traceroutes, the most popular tool that network engineers use to troubleshoot network performance. Subscribe to our blog for upcoming articles....

    非对称路径流量

    We have written a series of articles about traceroutes, the most popular tool that network engineers use to troubleshoot network performance. Subscribe to our blog for upcoming articles.

    我们写了一系列有关跟踪路由的文章,跟踪路由是网络工程师用来对网络性能进行故障排除的最受欢迎的工具。 订阅我们的博客以获取即将发表的文章。

    互联网流量不对称-如何捕获反向路径问题?(Internet Traffic is Asymmetrical — How to Catch Reverse Path Issues?)

    When looking at a traceroute, people often forget that traffic on the Internet is asymmetrical most of the time. It is called the Hot Potato Routing. As soon as an ISP has a packet with a destination address outside its own network, it will try to pass the packet to the next ISP ASAP.

    在查看路由时,人们通常会忘记Internet上的流量大部分时间都是不对称的。 这被称为“热土豆路由” 。 一旦ISP在其自己的网络之外具有目的地地址的数据包,它将尝试将该数据包尽快传递给下一个ISP。

    Obkio Internet Traffic is Asymmetrical — How to Catch Reverse Path Issues?
    Figure A — Normal Traffic Flow
    图A —正常交通流

    Figure A above is a good example of the Hot Potato Routing. In the figure, there are 2 ISPs (A and B) and they both have 3 routers located in New York City (NYC), Dallas (DAL) and San Francisco (SFO). In the 3 cities, the ISPs have interconnections to exchange traffic from one network to another.

    上面的图A是“热土豆路由”的一个很好的例子。 在图中,有2个ISP(A和B),并且它们都有3个位于纽约市(NYC),达拉斯(DAL)和旧金山(SFO)的路由器。 在这三个城市中,ISP具有互连功能,以将流量从一个网络交换到另一个网络。

    When the source SRC sends a packet to the destination DST, ISP A receives the packet on router A-NYC. As soon as it receives the packet, it will search for a way to send it to ISP B. In this case, the interconnection between the two routers in NYC is the fastest path to reach ISP B. The packet then continues its way inside ISP B up to the destination DST. The traceroute from SRC to DST will look like this:

    当源SRC将数据包发送到目标DST时,ISP A在路由器A-NYC上接收到该数据包。 收到数据包后,它将搜索将其发送到ISP B的方法。在这种情况下,NYC中两个路由器之间的互连是到达ISP B的最快路径。然后,数据包继续在ISP内部传播B到达目的地DST。 从SRC到DST的跟踪路由如下所示:

    +---+----------+-------+-----+------+------+------+------+
    | # | Hostname | Loss% | Snt | Last | Avg | Best | Wrst |
    +---+----------+-------+-----+------+------+------+------+
    | 1 | A-NYC | 0.0 | 1 | 1.0 | 1.0 | 1.0 | 1.0 |
    | 2 | B-NYC | 0.0 | 1 | 2.0 | 2.0 | 2.0 | 2.0 |
    | 3 | B-DAL | 0.0 | 1 | 40.0 | 40.0 | 40.0 | 40.0 |
    | 4 | B-SFO | 0.0 | 1 | 80.0 | 80.0 | 80.0 | 80.0 |
    | 5 | DST | 0.0 | 1 | 81.0 | 81.0 | 81.0 | 81.0 |
    +---+----------+-------+-----+------+------+------+------+
    Figure B - SRC to DST

    On the other side, when DST replies back to SRC, the packet goes from ISP B to A in SFO because this is the fastest route between the two networks. The forward traffic from SRC to DST uses a different path than the reverse traffic from DST to SRC. The traceroute from DST to SRC will look like this:

    另一方面,当DST回复SRC时,数据包从ISP B到SFO中的A,因为这是两个网络之间最快的路由。 从SRC到DST的前向流量使用与从DST到SRC的反向流量不同的路径。 从DST到SRC的跟踪路由如下所示:

    +---+----------+-------+-----+------+------+------+------+
    | # | Hostname | Loss% | Snt | Last | Avg | Best | Wrst |
    +---+----------+-------+-----+------+------+------+------+
    | 1 | B-SFP | 0.0 | 1 | 1.0 | 1.0 | 1.0 | 1.0 |
    | 2 | A-SFO | 0.0 | 1 | 2.0 | 2.0 | 2.0 | 2.0 |
    | 3 | A-DAL | 0.0 | 1 | 40.0 | 40.0 | 40.0 | 40.0 |
    | 4 | A-NYC | 0.0 | 1 | 80.0 | 80.0 | 80.0 | 80.0 |
    | 5 | SRC | 0.0 | 1 | 81.0 | 81.0 | 81.0 | 81.0 |
    +---+----------+-------+-----+------+------+------+------+
    Figure C - DST to SRC

    反向路径中的拥塞 (Congestion in the Reverse Path)

    Let’s take a look at the traceroute if there is congestion (50% packet loss) on the reverse path between A-DAL and A-SFO exactly at the red circle on Figure D below.

    让我们看一下traceroute,是否在A-DAL和A-SFO之间的反向路径上的拥塞(数据包丢失50%)正好在下面的图D中的红色圆圈处。

    Image for post
    Figure D — Congestion in the reverse path
    图D —反向路径中的拥塞

    The forward path traceroute will look like Figure E.

    前向路径traceroute将类似于图E。

    +---+----------+-------+-----+------+------+------+------+
    | # | Hostname | Loss% | Snt | Last | Avg | Best | Wrst |
    +---+----------+-------+-----+------+------+------+------+
    | 1 | A-NYC | 0.0 | 10 | 1.0 | 1.0 | 1.0 | 1.0 |
    | 2 | B-NYC | 0.0 | 10 | 2.0 | 2.0 | 2.0 | 2.0 |
    | 3 | B-DAL | 0.0 | 10 | 40.0 | 40.0 | 40.0 | 40.0 |
    | 4 | B-SFO | 50.0 | 10 | 80.0 | 80.0 | 80.0 | 80.0 |
    | 5 | DST | 50.0 | 10 | 81.0 | 81.0 | 81.0 | 81.0 |
    +---+----------+-------+-----+------+------+------+------+
    Figure E - SRC to DST during congestion

    The traceroute clearly indicates a network issue because the packet loss continues below hop 4. Learn more on how to analyze a traceroute with the article How To Identify Network Issues with Traceroutes?.

    跟踪路由清楚地指示网络问题,因为数据包丢失在第4跳以下继续。有关如何分析跟踪路由的更多信息,请参见文章如何通过跟踪路由来识别网络问题?

    If the forward and the reverse paths were the same, we could say that there is congestion inside ISP B between Dallas and San Francisco. But we know it’s not that. The congestion is in ISP A’s network. The reverse path traceroute will show us the other side of the medal:

    如果前进和后退路径相同,则可以说ISP B内部在达拉斯和旧金山之间存在拥塞。 但是我们知道不是那样的。 拥塞发生在ISP A的网络中。 反向路径跟踪路线将向我们展示奖牌的另一面:

    +---+----------+-------+-----+------+------+------+------+
    | # | Hostname | Loss% | Snt | Last | Avg | Best | Wrst |
    +---+----------+-------+-----+------+------+------+------+
    | 1 | B-SFP | 0.0 | 10 | 1.0 | 1.0 | 1.0 | 1.0 |
    | 2 | A-SFO | 0.0 | 10 | 2.0 | 2.0 | 2.0 | 2.0 |
    | 3 | A-DAL | 50.0 | 10 | 40.0 | 40.0 | 40.0 | 40.0 |
    | 4 | A-NYC | 50.0 | 10 | 80.0 | 80.0 | 80.0 | 80.0 |
    | 5 | SRC | 50.0 | 10 | 81.0 | 81.0 | 81.0 | 81.0 |
    +---+----------+-------+-----+------+------+------+------+
    Figure F - DST to SRC during congestion

    So in that example, Figure F, the reverse traceroute from DST to SRC gave us the good answer about where the problem was, but unfortunately, there is no way for us to know which traceroute (forward or reverse) is exact. However, with that information in hand, the network engineer at ISP A and B can help troubleshoot the network issue that is affecting the traffic between SRC and DST.

    因此,在图F的示例中,从DST到SRC的反向跟踪路由为我们提供了有关问题出在哪里的好答案,但是不幸的是,我们无法知道哪个跟踪路由(正向或反向)是正确的。 但是,有了这些信息,ISP A和B的网络工程师可以帮助解决影响SRC和​​DST之间流量的网络问题。

    To help troubleshoot the issue further, traceroutes from sources and destinations that are in the same ISP can help locate the exact issue.

    为了帮助进一步解决问题,来自同一ISP中源和目标的跟踪路由可以帮助找到确切的问题。

    达拉斯互连网的拥堵 (Congestion at the Dallas Interconnection)

    Networks are complex. There are millions of connections on the Internet where a network issue can happen. Let’s see what happens if there is 50% packet loss on the Dallas interconnection between ISP A and B.

    网络很复杂。 Internet上有数百万个连接,可能会发生网络问题。 让我们看看如果ISP A和B之间的达拉斯互连上的数据包丢失50%,会发生什么情况。

    Image for post
    Figure G — Congestion at the Dallas interconnection
    图G –达拉斯互连处的拥堵

    The two traceroutes look like this:

    这两个跟踪路由如下所示:

    +---+----------+-------+-----+------+------+------+------+
    | # | Hostname | Loss% | Snt | Last | Avg | Best | Wrst |
    +---+----------+-------+-----+------+------+------+------+
    | 1 | A-NYC | 0.0 | 10 | 1.0 | 1.0 | 1.0 | 1.0 |
    | 2 | B-NYC | 0.0 | 10 | 2.0 | 2.0 | 2.0 | 2.0 |
    | 3 | B-DAL | 50.0 | 10 | 40.0 | 40.0 | 40.0 | 40.0 |
    | 4 | B-SFO | 0.0 | 10 | 80.0 | 80.0 | 80.0 | 80.0 |
    | 5 | DST | 0.0 | 10 | 81.0 | 81.0 | 81.0 | 81.0 |
    +---+----------+-------+-----+------+------+------+------+
    Figure H - SRC to DST during congestion in Dallas+---+----------+-------+-----+------+------+------+------+
    | # | Hostname | Loss% | Snt | Last | Avg | Best | Wrst |
    +---+----------+-------+-----+------+------+------+------+
    | 1 | B-SFP | 0.0 | 10 | 1.0 | 1.0 | 1.0 | 1.0 |
    | 2 | A-SFO | 0.0 | 10 | 2.0 | 2.0 | 2.0 | 2.0 |
    | 3 | A-DAL | 50.0 | 10 | 40.0 | 40.0 | 40.0 | 40.0 |
    | 4 | A-NYC | 0.0 | 10 | 80.0 | 80.0 | 80.0 | 80.0 |
    | 5 | SRC | 0.0 | 10 | 81.0 | 81.0 | 81.0 | 81.0 |
    +---+----------+-------+-----+------+------+------+------+
    Figure I - DST to SRC during congestion In Dallas

    As we learned in the article How To Identify Network Issues with Traceroutes?, if the packet loss doesn’t continue, don’t panic, there is no network issue. Well, it’s correct to assume that there is no network issue affecting the traffic from SRC to DST, but in that special case, all the ICMP TTL Exceeded responses from B-DAL to SRC are dropped at the interconnection issue because B-DAL is using the shortest path (i.e. the interconnection) to send back the packet. On the other side, the responses from A-DAL to DST are also dropped.

    正如我们在文章如何通过Traceroutes识别网络问题中所学到的那样,如果数据包丢失没有继续发生,请不要惊慌,则没有网络问题。 好吧,假设没有网络问题影响从SRC到DST的流量是正确的,但是在这种特殊情况下,由于B-DAL正在使用,所以从B-DAL到SRC的所有ICMP TTL超出响应都被丢弃了。发送数据包的最短路径(即互连)。 另一方面,从A-DAL到DST的响应也被丢弃。

    Now you understand why it’s important to have a reverse traceroute to compare the data. It’s also clear that a single traceroute can be misleading, so we must be careful when we think that we’ve pinpointed a network issue.

    现在您了解了为什么使用反向跟踪路由来比较数据很重要。 同样清楚的是,单个跟踪路由可能会产生误导,因此当我们认为已查明网络问题时,必须小心。

    As one can imagine, a network performance monitoring solution like Obkio offers reverse traceroute to help troubleshoot network issues.

    可以想象,像Obkio这样网络性能监视解决方案提供了反向跟踪路由,可以帮助解决网络问题。

    下一篇Traceroute文章 (Next Traceroute Articles)

    This is the end of this first article on traceroutes. The next articles will cover how to analyze traceroutes and which information is the most important.

    这是有关跟踪路由的第一篇文章的结尾。 下一篇文章将介绍如何分析跟踪路由以及哪些信息最重要。

    We hope you enjoyed this article in the traceroute series. Subscribe to our blog for upcoming articles.

    我们希望您喜欢traceroute系列文章。 订阅我们的博客以获取即将发表的文章。

    翻译自: https://medium.com/obkio/internet-traffic-is-asymmetrical-how-to-catch-reverse-path-issues-adebd8798ec1

    非对称路径流量

    展开全文
  • 单播反向路径转发uRPF

    2018-12-22 22:48:00
    :仅检查数据包的源地址是不是在FIB中,不检查源地址是不是由最佳返回路径的接口接收,松散模式的灵活性更大,一般在多宿主连接(包括网络内部)普遍存在的情况下使用。     注意:uRPF只能在输入接口使用 。因此...

    uRPF将数据包的源地址和存储在转发信息库(FIB)中的信息进行对照,以判定数据包的合法性。FIB是Cisco CEF技术中的一张表,包含从路由表中复制过来的转发信息,可以将其视为路由表的镜像,FIB包含所有已知的路由信息,设备采用FIB就能提高数据包转发的速度,由于uRPF以FIB中的信息为过依据,因此在使用uRPF之前必须首先配置CEF

    uRPF的两种工作模式:

        • 严格模式(strict):检查数据包的源地址是否在FIB中,且源地址是否是CEF确定的最佳返回路由接口接收。
        在多宿主连接中,有可能返回的最佳连接与接收接口不同,这样容易产生问题。鉴于此尽在单宿主连接中使用该模式,若存在多条相同度量的最佳路径也可以使用uRPF,如配置了度量方差(Metric variance)的EIGRP。
        建议一下两种情况使用严格模式:1、仅有一条进出网络的连接;2、满足要求的单宿主客户与核心网络连接。
        
        • 松散模式(loose):仅检查数据包的源地址是不是在FIB中,不检查源地址是不是由最佳返回路径的接口接收,松散模式的灵活性更大,一般在多宿主连接(包括网络内部)普遍存在的情况下使用。
        
        注意:uRPF只能在输入接口使用。因此,若网络和ISP之间存在一条单宿主主连接,则应该只配置uRPF以监控来自ISP的流量。由于uRPF以CEF转发速率工作,与采用传统的ACL防止地址欺骗相比,uRPF可以有效提高设备的性能,当uRPF被配置在工作速率超过1Mbps的接口,此区别将更加明显。

    uRPF配置:


    可以看出在模式选项后面还可以配合ACL使用,以确定数据包的转发或丢弃。
    注意,仅在数据包无法通过uRPF校验时,才需要使用ACL。


    验证uRPF配置:
    查看指定接口配置的uRPF:
    show cef interface interface

    查看全局uRPF数据包计数信息:

    show ip traffic //会出现很多statistics,如IP、ICMP、IGMP、OSPF、PIM等

    查看指定接口丢弃(验证丢弃)或转发(抑制验证丢弃)uRPF数据包的信息:

    show ip interface interface

     

    转载于:https://www.cnblogs.com/MomentsLee/p/10162775.html

    展开全文
  • 在复杂的网络环境中应用URPF时,会遇到路由不对称的情况,即对端设备记录的路由路径不一致,此时使用URPF的设备可能会丢弃合法报文,造成设备不能正常转发; 为了解决以上复杂网络中应用URPF的问题,设备实现了URPF...

    URPF协议原理

    1、工作模式
    在复杂的网络环境中应用URPF时,会遇到路由不对称的情况,即对端设备记录的路由路径不一致,此时使用URPF的设备可能会丢弃合法报文,造成设备不能正常转发;
    为了解决以上复杂网络中应用URPF的问题,设备实现了URPF的两种工作模式:
    (1)严格模式
    严格模式下,设备不仅要求报文源地址在FIB表中存在相应表项,还要去接口匹配才能通过URPF检查;
    建议在路由对称的环境下使用URPF严格模式,例如两个网络边界设备之间只有一条路径的话,这时使用严格模式能够最大限度的保证网络的安全性;

    (2)松散模式
    松散模式下,设备不检查接口是否匹配,只要FIB表中存在该报文源地址的路由,报文就可以通过;
    建议在不能保证路由对称的环境下使用URPF的松散模式,例如两个网络边界设备之间如果有多条路径连接的话,路由的对称性就不能保证,在这种情况下,URPF的松散模式也可以保证较强的安全性;

    2、工作原理
    URPF通过获取报文的源地址和入接口,在FIB表中查找源地址对应的接口是否与入接口匹配,如果不匹配则认为源地址是伪装的,丢弃该报文,通过这种方式,URPF能够有效地防范网络中通过修改源地址而进行的恶意攻击行为;
    在这里插入图片描述
    如上图所示,在SWA上伪造源地址为2.1.1.1的报文向SWB发起请求,SWB响应请求时将向真正的2.1.1.1即SWC发送报文,这种非法报文对SWB和SWC都造成了攻击;
    如果在SWB上启用了URPF,则SWB在收到源地址为2.1.1.1的报文时,URPF检查到以此报文源地址对应的接口与收到该报文的接口不匹配时,报文会被丢弃;

    展开全文
  • uRPF(Unicast Reverse Path Forwarding)是一种单播反向路由查找技术,用于防止基于源地址欺骗的网络攻击行为。 URPF技术会首先获取包的源地址和入接口,而后以源地址为目的地址,在路由转发表中查找相对应的转发...
  • 基于发送源的 IP 地址(数据包中的源地址)来转发 。... Selective Forwarding(选择性转发)如果有多条转发路 径可用,则依靠单播路由表来帮助选择最佳路径 一 路由器只转发从可达源的上游路由器...
  • HTTP路径反向代理

    2011-10-27 18:04:55
    HTTP路径反向代理,将远端HTTP服务反向代理到本地HTTP子目录下,解析修改HTTP请求头与响应头并修改链接位置,重定义Content-Length,遇到HTTP响应gzip压缩编码时解压后进行修改并可以重新gzip压缩发回用户,用户可以...
  • nginx配置反向代理路径问题

    千次阅读 2020-07-03 13:02:26
    用nginx上了个前端项目,踩了路径的坑,记录一下: server { listen 2077; server_name localhost; location / { root html; index index.html index.htm; } # 例如:你前端的请求路径是这样的 /api/v1/get...
  • 老早以前就有所耳闻,但是没用过,最近开始用Python做web开发才开始接触,发现果然是异常强大,今天又把老网站服务器倒腾了一下,换成tomcat+nginx跑起来,记录一下外网的服务器配置识别移动终端走不同的反向代理路径过程 ...
  • 434
  • nginx 反向代理location路径设置

    千次阅读 2019-07-06 09:29:27
    更多文章欢迎访问程序员小非博客 ...此时proxy_pass后面的路径必须和location设置的路径一致: location /index { proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remot...
  • 路径规划之反向搜索

    2019-05-20 12:54:36
    在D*算法及D* lite算法的论文中提到了“backward”,在译文中它被翻译为"反向所搜",那么反向搜索的好处提现在哪里呢?在这里举个例子: 如果正向搜索显然会因为很多分支导致效率下降,但是如果反向搜索会得到如下...
  • nginx 配置 proxy_pass时可以实现URL路径的部分替换。 1.proxy_pass的目标地址,默认不带/,表示只代理域名,url和querystring部分不会变(把请求的path拼接到proxy_pass目标域名之后作为代理的URL) 2.如果在目标...
  • "/"问题 访问www.xxxx.com/api 配置1:proxy_pass末尾不加 / location /api/ { proxy_pass http://localhost:8080; } 实际访问的是: ...总结:加 / 不带路径(api),不加 / 带路径
  • 注意:设置反向代理后,项目静态资源如果不在cdn上而在本地,那么:1、如果是绝对路径,绝对路径前缀不符合代理的就不会走代理,可能导致资源无法找到;2、如果是相对路径(相对路径是以当前浏览器地址栏中的url路径...
  • = 200000), 每条边有一个权值, 求从第一个点到n的最少步数, 如果最少步数相同有多条路径, 那么输出权值字典序最小的一条。 分析: 用BFS解决最短路问题, 可以先从终点BFS, 求出每个点到终点的最短距离。 ...
  • 解决反向代理的绝对路径问题

    千次阅读 2015-04-28 10:46:42
    由于需要在windows系统上实现一个反向代理功能,因此就考虑到使用apache。 Apache具有反向代理的功能。通过对文件httpd.conf,进行简单的设置,即可以实现反向代理功能。但是被代理的服务中,如果包含有绝对路径的...
  • 到达终点B的最短路径,为了到达终点,我们不可避免的就需要经过每一个点(松弛操作),那么如果由多个终点到达某一个点,那么我们需要把很多次Dijkstra或者Spfa吗,或者说直接来一个Floyd(前提是点数很少,毕竟O(n^3)),那么...
  • 在配置nginx反向代理的时候发现匹配路径上的一些问题。 问题: 1.如图这两种配置方式其实实现的代理是一样的效果。也就是说proxy_pass后没有追加匹配到的请求路径,真正的请求路径就是 ...
  • nginx反向代理带路径访问问题

    千次阅读 2018-01-18 09:08:00
    nginx的配置为192.168.0.219:80分别映射到upstream组192.168.0.55:8080和192.168.0.206:8080,那如何配置做到访问192.168.0.219:80时...这个主要是要做一个反向代理,具体配置如下:   1 2 3 4 5 6 7 8 9 10 11...
  • nginx反向代理配置及指向本地路径

    万次阅读 2018-04-17 19:36:27
    nginx作为web服务器一个重要的功能就是反向代理。 nginx反向代理的指令不需要新增额外的模块,默认自带proxy_pass指令,只需要修改配置文件就可以实现反向代理。配置前的准备工作,后端跑apache服务的ip和端口,也...
  • 被动IP追溯:从路径反向散射公开IP欺骗者的位置

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 2,858
精华内容 1,143
关键字:

反向路径