Wêrom it blokkearjen fan alle ICMP in wurkjende VPN-rûte brekt
Grutte-feedbackberjochten binne gjin ping-antwurden. As se nea oankomme, slagje lytse pakketten, ferdwine grutte, en liket de tunnel te fladderjen.
In tunnel dy't autentisearret, in ping draacht en dan by de earste grutte oerdracht hinget, is it klassike teken fan in ûntbrekkend ICMP-berjocht ynstee fan in stikken VPN. De stjoerder leart nea dat in pakket te grut wie, besiket deselde grutte op 'e nij, en de applikaasje wachtet. Dit reparearje is in beslút oer firewallbelied, net it op 'e nij ynstallearjen fan de klient. De folchoarder is fan belang: mjit wêr't de gruttegins leit, en fernau dan de regel dy't it rapport opslokte.
Wat ICMP wier op dit paad draacht
IPv4-paad-MTU-ûntdekking berêst derop dat in router rapportearret dat in pakket mei de don't-fragment-bit set net trochstjoerd wurde koe. Dat rapport is in ICMP Fragmentation Needed-berjocht, en sûnder dat hat de stjoerder gjin reden om syn segmintgrutte te ferlytsjen. IPv6 is stranger: routers fragmintearje net yn transit, dus in ICMPv6 Packet Too Big-berjocht is it iennige sinjaal dat de stjoerder krimpe lit.
Beide berjochten binne feedback fan it kontrôleflak, en gjin fan beide is in diagnostyske echo. In belied dat ping blokkearret en in belied dat alle ICMP blokkearret lykje op in regellist, mar gedrage har hiel oars op it netwurk. It twadde kin in goed dimensjonearre tunnel feroarje yn in ienrjochtingspaad foar alles grutter as de lytste skeakel yn 'e keatling.
Guon transporten ymplementearje har eigen ûntdekking mei sondepakketten, sa't RFC 4821 beskriuwt, en dy binne minder ôfhinklik fan dizze feedback. Dat is in argumint om te kontrolearjen hokker transportsto jo brûke, net om oan te nimmen dat elke tunnel ymmún is.
| Berjocht | Doel op it paad | As blokkearre |
|---|---|---|
| ICMPv4 type 3 koade 4 | It pakket wie te grut foar de folgjende skeakel | De stjoerder besiket it op 'e nij en hinget |
| ICMPv6 type 2 | Packet Too Big, it IPv6-ekwivalint | Deselde hingjen, sûnder fragmintaasjefallback |
| ICMP type 11 | Tiid ferstruten, brûkt troch traceroute | Diagnostyk ferliest hops, ferkear streamt noch |
| ICMP-echofersyk en -antwurd | Berikberheidstest | Ping mislearret, it paad kin goed wêze |
De flater hinget fan 'e grutte ôf
Freegje oft de flater korrelearret mei pakketgrutte. In oanmeldside, DNS-fraach en koarte API-oprop slagje, wylst in bestânsoerdracht, in grut antwurd of in bylddownload hinget. Dat patroan wiist op in gruttegins earne tusken de beide einen, net op autentikaasje of routing. In slagge lytse ping seit hast neat oer wêr't dy grins leit.
Binnen in tunnel binne der twa lagen om te beskôgjen: it ladingspakket en it bûtenste ynkapsulearre pakket. De binnenste stjoerder kin him korrekt gedrage wylst it bûtenste paad lytser is as de tunnel oannimt, en dêrom binne sawol de eigen MTU-ynstelling fan 'e tunnel as de fysike skeakel dêrûnder fan belang.
Mjit foardat jo regels bewurkje
Sondearje mei de don't-fragment-bit en in ladinggrutte dy't jo sels kieze, fan 'e mislearjende klient nei in beskerme adres:
ping -M do -s 1472 10.20.5.7
ping -M do -s 1300 10.20.5.7In lading fan 1472 byte plus 28 byte oan kopteksten is in pakket fan 1500 byte. As de grutte sonde mei in fragmintaasjeflater mislearret en de lytsere trochkomt, hawwe jo de grins fûn; pas oan foar tunnel-oerhaad en werhelje oant de wurkjende grutte stabyl is.
Befêstigje dan dat de kleau it rapport sels is. As de sonde stil mislearret, sûnder flater en sûnder antwurd, wurdt it berjocht wierskynlik weilitten ynstee fan levere, en de regel is de fertochte.
Fernau de regel en test de taak dan op 'e nij
De korreksje moat de spesifike kontrôleberjochten tastean, net it hiele protokol. Op in iptables-host is de foarm in type-spesifike talitting; pas de syntaksis oan by wat de firewall op jo platfoarm beheart:
iptables -I INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
ip6tables -I INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPTHâld echo-antwurden blokkearre as dat it pleatslike belied is, want it paad hat se net nedich. Test dan de oerdracht dy't oarspronklik mislearre op 'e nij, fan in nije ferbining, en befêstigje dat de regelballers sjen litte dat de berjochten oankomme.
As de grutte oerdracht noch hinget neidat de berjochten tastien binne, is de oerbliuwende grin earne oars: in tunnel-MTU dy't te heech set is, in proxy dy't pakketten oerskriuwt, of in tuskenbak dy't weilitten ynstee fan rapportearret. De ICMP-regel wie nedich, net genôch.