Ping gennem en VPN: hvorfor regler for ekko-svar rammer forbi returvejen
Et ekko-svar ændrer ICMP-type, ikke en serviceport. Følg den indre pakke gennem videresendelse, NAT og det stateful filter, før du åbner porte.
Ping en vært gennem en VPN, og anmodningen forlader med én ICMP-type og vender tilbage med en anden, hvilket er nok til at forvirre enhver regel skrevet i porttermer. Der findes ingen destinationsserviceport i en ekkoudveksling at kopiere ind i returreglen, og et filter, der forventer symmetri, vil droppe svaret, mens anmodningen passerer uhindret. Rettelsen begynder med at læse pakken, som den faktisk er, og derefter afgøre, hvilken grænse på vejen der træffer beslutningen. Normalt arbejder to lag, mens det tredje lydløst dropper svaret. Afsnittene nedenfor adskiller dem i den rækkefølge, en pakke møder dem.
Pakken skifter type, ikke port
En ekkoanmodning er ICMP-type 8, kode 0, og bærer et id og et sekvensnummer. Svaret er type 0, kode 0, med det samme id og sekvensnummer, og IP-endepunkterne byttet om. RFC 792 definerer disse felter, og id'et er det, der lader en afsender matche svar med sine egne anmodninger.
Det, der mangler, er lige så vigtigt: der er ingen TCP- eller UDP-header, så der er ingen port at tillade. En regel, der navngiver en port til et ekko-svar, beskriver en pakke, der aldrig vil eksistere. Det er den enkeltvis mest almindelige fejl i VPN-ping-tickets. Reglen ser specifik ud, gælder for ingenting og efterlader fejlen præcis, hvor den var.
Tre kontekster afgør pakken
Hvis pinget sigter mod en vært på det fjerne LAN, skal anmodningen videresendes af gatewayen. Hvis det sigter mod en adresse, der tilhører gatewayen selv, afsluttes det i den lokale inputvej i stedet. Hvis gatewayen selv starter pinget, begynder pakken i dens egen outputvej og krydser slet ikke videresendelsesbeslutningen.
Disse tre kontekster har forskellige regelkæder og forskellige tællere, og det er behandlingen af dem som én, der gør, at «firewallen tillader ICMP» stadig kan give et mislykket ping. Den ydre tunnel er en fjerde kontekst: at tillade VPN-lytteren tillader ikke automatisk den dekapsulerede indre anmodning, og en indre tilladelse siger intet om, hvorvidt den ydre tunnel er oppe.
Stateful og stateless filtre håndterer svaret forskelligt
En stateful firewall, der så anmodningen forlade, kan knytte svaret til den strøm og lukke det ind uden en anden regel. Et stateless filter har ingen sådan hukommelse, så returretningen har brug for sin egen udtrykkelige tilladelse med kilde og destination ombyttet.
Kontroller, hvilken model produktet faktisk implementerer, før du skriver noget. En regel for ekkoanmodning dækker ikke nødvendigvis ekko-svar, og et produkt, der følger ICMP-forespørgsler, kan stadig anvende en anden politik på svar, der ankommer på en anden grænseflade.
Afgræns, hvad du tillader. At tillade hvert ekko-svar fra hvor som helst er ikke det samme som at fuldføre en stateful sammenkædning, og et typenummer autentificerer ikke afsenderen.
Oversættelse ændrer også id'et
Hvis kildeoversættelse er tilsigtet, matcher tuplen i den fjerne ende ikke den, klienten sendte. En NAT kan oversætte ICMP-forespørgsels-id'et sammen med adresserne, så insisteren på, at det samme nummer vises på begge sider, giver en falsk uoverensstemmelse.
Korrelér i stedet den mapping, oversætteren rapporterer. En oversætter, der omskriver id'et, bevarer ikke det nummer, din klient loggede, så behandl mappingen som identiteten frem for nummeret. Følg derefter én identificerbar anmodning gennem vejen: bekræft, at den når destinationen med den forventede kilde, bekræft, at destinationen udsendte et svar, følg det svars rute tilbage, og bekræft, at klienten modtog det, i stedet for blot at se en gateway-tæller stige.
Flett ikke ICMP-fejl ind i ekkopolitikken
Den «fragmentering nødvendig»-meddelelse, som path-MTU-opdagelse bruger, er ikke et ekko-svar, og dens nyttelast citerer den pakke, der udløste den. En tilladelse kun for ekko, der lydløst kasserer disse fejl, gør et størrelsesproblem til en hængende forbindelse, hvilket er det modsatte af hjælpsomt.
Samme forsigtighed gælder for adressefamilier. ICMPv6 bruger andre meddelelsestyper og bærer væsentlige funktioner, som IPv4 ikke har, så at kopiere disse numre ind i en IPv6-regel er simpelthen forkert.
Når ekkoudvekslingen virker, test den rigtige applikation separat. Et vellykket ping beviser én protokols rundtur ved én størrelse til én destination, og det er ikke en licens til at antage, at HTTPS, SMB eller enhver anden strøm er tilladt.