Miért töri meg a működő VPN-útvonalat az összes ICMP blokkolása
A méret-visszajelző üzenetek nem ping-válaszok. Ha soha nem érkeznek meg, a kis csomagok átmennek, a nagyok eltűnnek, és az alagút úgy tűnik, mintha villogna.
Az az alagút, amely hitelesít, átvisz egy pinget, majd elakad az első nagy átvitelnél, a hiányzó ICMP-üzenet klasszikus jele, nem a tönkrement VPN-é. A küldő soha nem tudja meg, hogy egy csomag túl nagy volt, ugyanazt a méretet próbálja újra, az alkalmazás pedig vár. Ennek javítása tűzfal-szabályzati döntés, nem az ügyfél újratelepítése. A sorrend számít: mérje meg, hol van a mérethatár, majd szűkítse le azt a szabályt, amely elnyelte a jelentést.
Mit szállít valójában az ICMP ezen az útvonalon
IPv4 útvonal-MTU felderítés azon alapul, hogy egy útválasztó jelenti: a don't-fragment bittel ellátott csomagot nem lehetett továbbítani. Ez a jelentés egy ICMP Fragmentation Needed üzenet, és nélküle a küldőnek nincs oka csökkenteni a szegmensméretét. Az IPv6 szigorúbb: az útválasztók tranzitban nem darabolják a csomagokat, így az ICMPv6 Packet Too Big üzenet az egyetlen jel, amelytől a küldő zsugorodik.
Mindkét üzenet a vezérsík visszajelzése, és egyik sem diagnosztikai visszhang. A pinget blokkoló szabályzat és az összes ICMP-t blokkoló szabályzat hasonlónak tűnik a szabálylistán, de a hálózaton nagyon különbözően viselkedik. A második a helyesen méretezett alagutat egyirányú útvonallá teheti minden olyan dolog számára, amely nagyobb a lánc legkisebb szeménél.
Egyes átvitelek saját felderítést valósítanak meg próbacsomagokkal, ahogy az RFC 4821 leírja, és ezek kevésbé függnek ettől a visszajelzéstől. Ez érv amellett, hogy ellenőrizze, melyik átvitelt futtatja, nem amellett, hogy feltételezze: minden alagút immunis.
| Üzenet | Cél az útvonalon | Ha blokkolják |
|---|---|---|
| ICMPv4 3. típus, 4. kód | A csomag túl nagy volt a következő szakaszhoz | A küldő újrapróbálja és elakad |
| ICMPv6 2. típus | Packet Too Big, az IPv6 megfelelője | Ugyanaz az elakadás, darabolási tartalék nélkül |
| ICMP 11. típus | Időtúllépés, a traceroute használja | A diagnosztika ugrásokat veszít, a forgalom tovább folyik |
| ICMP visszhangkérés és -válasz | Elérhetőségi teszt | A ping meghiúsul, az útvonal rendben lehet |
A hiba méretfüggő
Kérdezze meg, korrelál-e a hiba a csomagmérettel. Egy bejelentkező oldal, egy DNS-lekérdezés és egy rövid API-hívás átmegy, miközben egy fájlfeltöltés, egy nagy válasz vagy egy kép letöltése elakad. Ez a minta a két végpont közötti mérethatárra utal, nem a hitelesítésre vagy az útválasztásra. Egy sikeres kis ping szinte semmit sem mond arról, hol van ez a határ.
Egy alagúton belül két réteget kell figyelembe venni: a hasznos csomagot és a külső, beágyazott csomagot. A belső küldő helyesen viselkedhet, miközben a külső útvonal kisebb, mint amit az alagút feltételez, ezért számít az alagút saját MTU-beállítása és az alatta lévő fizikai szakasz is.
Mérjen, mielőtt szabályokat szerkeszt
Vizsgáljon don't-fragment bittel és az Ön által választott hasznos mérettel, a hibás ügyféltől egy védett cím felé:
ping -M do -s 1472 10.20.5.7
ping -M do -s 1300 10.20.5.7Az 1472 bájtos hasznos teher plusz 28 bájt fejléc 1500 bájtos csomagot ad. Ha a nagy próba töredezési hibával meghiúsul, a kisebb pedig átmegy, megtalálta a határt; számoljon az alagút többletével, és ismételje, amíg a működő méret stabillá válik.
Ezután erősítse meg, hogy a rés maga a jelentés. Ha a próba csendben hiúsul meg, hiba és válasz nélkül, az üzenetet valószínűleg eldobják ahelyett, hogy kézbesítenék, és a gyanús a szabály.
Szűkítse a szabályt, majd tesztelje újra a feladatot
A javításnak az adott vezérlőüzeneteket kell engedélyeznie, nem a teljes protokollt. Egy iptables-gazdagépen a forma típus szerinti engedélyezés; igazítsa a szintaxist ahhoz, ami az Ön platformján a tűzfalat kezeli:
iptables -I INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
ip6tables -I INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPTHagyja blokkolva a visszhangválaszokat, ha ez a helyi szabályzat, mert az útvonalnak nincs rájuk szüksége. Ezután tesztelje újra az eredetileg meghiúsult átvitelt új kapcsolatból, és erősítse meg, hogy a szabály számlálói mutatják az üzenetek érkezését.
Ha a nagy átvitel az üzenetek engedélyezése után is elakad, a fennmaradó korlát máshol van: túl magasra állított alagút-MTU, csomagokat átíró proxy vagy olyan köztes eszköz, amely eldob a jelentés helyett. Az ICMP-szabály szükséges volt, de nem elégséges.