Problema bitului DF și fragmentarea în tunelurile GRE
Uneori, atunci când traficul trece prin tunelul GRE, puteți ping cu succes orice gazdă de pe Internet, dar nu puteți naviga pe Web sau transfera fișiere utilizând protocolul FTP. În această lucrare vom examina cauzele obișnuite ale acestei probleme și vom oferi mai multe soluții.
Fragmentarea pachetelor și mesajele ICMP
Luați în considerare schema de rețea prezentată mai jos. Două routere R1 și R2 au format un tunel GRE.
În această diagramă, atunci când clientul dorește să acceseze o pagină web pe Internet, stabilește o sesiune TCP cu serverul Web. În timpul acestui proces, Clientul și serverul Web își anunță reciproc maximul segmentului de dimensiune (MSS), indicând faptul că pot primi segmente TCP până la această dimensiune. După ce primește opțiunea MSS, fiecare dispozitiv calculează dimensiunea segmentului care poate fi trimis. Aceasta se numește Dimensiunea maximă a segmentului trimiterii (SMSS) și este egală cu cea mai mică valoare a celor două MSS.
Pentru exemplul nostru, serverul Web decide că poate trimite pachete de până la 1500 de octeți. Prin urmare, acesta trimite un pachet de 1500 de octeți către client și, în antetul IP, stabilește bitul DF (nu fragment), adică pachetul nu poate fi fragmentat. Când pachetul ajunge la R2, router-ul încearcă să îl încapsuleze în pachetul tunel. În cazul interfeței tunelului GRE, MTU IP este de 24 de octeți mai mic decât IP MTU a interfeței reale de ieșire. Pentru interfața Ethernet ieșită, aceasta înseamnă că MTU-ul IP pe interfața tunelului va fi 1500 minus 24 sau 1476 octeți.
R2 încearcă să împacheteze un pachet IP de 1500 de octeți într-o interfață MTU de 1476 octeți. Din moment ce acest lucru nu este posibil, R2 trebuie să fragmenteze pachetul, creând un pachet de 1476 octeți (date și antetul IP) și un pachet de 44 biți (24 octeți de date și un nou antet IP de 20 octeți). R2 apoi încapsulează ambele pachete pentru a primi pachete de 1500 și, respectiv, 68 octeți. Aceste pachete pot fi trimise acum printr-o interfață reală care are un MTU IP de 1500 de octeți.
Cu toate acestea, rețineți că pachetul primit de ruterul R2 are setul de biți DF. Astfel, R2 nu poate fragmenta pachetul și, în schimb, instruiește serverul Web să trimită pachete mai mici. Ea face acest lucru prin trimiterea unui server de web ICMP de tip 3 cod 4 pachete (destinație inaccesibilă; Fragmentarea necesare și setul DF), ceea ce înseamnă că nodul specificat nu este disponibil, fragmentarea necesară, dar DF bit setat. Acest mesaj ICMP conține MTU corect pentru serverul Web, care ar trebui să îl primească și să ajusteze dimensiunea pachetului în consecință.
Putem vedea pachetele ICMP recuperate de la R2 folosind comanda debug ip icmp.
ICMP: dst (10.10.10.10) frag. necesare și DF setat de nerealizat trimis la 10.1.3.4
În mod obișnuit, problema apare atunci când mesajele ICMP sunt blocate pe calea spre serverul Web. Când se întâmplă acest lucru, pachetul ICMP nu ajunge niciodată pe serverul Web, împiedicând astfel fluxul de date între client și server. Rezolvați această problemă în oricare din cele patru moduri:
Aflați unde sunt blocate mesajele ICMP și vedeți dacă le putem rezolva pasajul.
Instalați MTU pe interfața Client la 1476 octeți, forțând SMSS să fie mai mică, astfel încât pachetele să nu fie nevoie să fie fragmentate atunci când ajung la R2. Cu toate acestea, dacă modificați MTU pentru Client, trebuie să modificați și MTU-ul pentru toate dispozitivele care se află în această rețea cu acest Client. Pe segmentul Ethernet poate fi un număr destul de mare de dispozitive.
Utilizați un server proxy între R2 și gateway-ul dvs.
?php include ($ _SERVER ["DOCUMENT_ROOT"]. "/ vstavki / blokvtext2.php"); ?>
Dacă opțiunile de mai sus nu sunt fezabile, atunci următoarele soluții pot fi utile:
1) Utilizați rutarea politică (PBR) pentru a reseta bitul DF în pachetele IP
interfață Ethernet0
.
ip politica ruta-harta clear-df
harta permisului clear-df 10
potriveste adresa IP 101
set ip df 0
lista de acces 101 permite tcp 10.1.3.0 0.0.0.255 oricare
Această configurație va permite fragmentarea pachetului IP înainte de a fi încapsulat în GRE. Gazda receptoare ar trebui apoi să compileze pachetele IP din fragmente. Aceasta nu este de obicei o problemă.
2. Modificați valoarea opțiunii TCP MSS din pachetele SYN care trec prin router. Aceasta va reduce valoarea MSS în pachet TCP SYN, astfel încât acesta va fi mai mică sau egală cu valoarea din comanda ip TCS ajusta-MSS, în acest caz, 1436 (MTU IP dimensiune minus, TCP, și antetul GRE). Acum, gazda destinație va trimite pachete TCP / IP nu mai mari decât această valoare.
3. O opțiune final este de a crește IP MTU pe interfața tunel la o valoare de 1500. Cu toate acestea, creșterea tunelare IP MTU va duce la faptul că pachetele de tuneluri sunt fragmentate, deoarece bitul DF nu este pachetul original este copiat în antetul GRE. În acest scenariu, ruterul de la celălalt capăt al tunelului GRE trebuie să reasambleze pachetul GRE înainte ca acesta să poată șterge antetul GRE și să înainteze pachetul interior.
Pachetul IP este construit pe CPU și utilizează în mod activ memoria routerului. Prin urmare, această alegere poate reduce semnificativ transferul de pachete prin tunelul GRE.
În concluzie, motivul cel mai frecvent pentru faptul că nu se poate naviga pe Internet pe tunelul GRE este din cauza problemei de fragmentare de mai sus. Soluția este de a permite ICMP să treacă sau să soluționeze soluția ICMP prin oricare dintre metodele de mai sus.
Trimiteți-le prietenilor: