Consideram topologia de mai jos cu routerele R1, R2 si R3. Fiecare dintre cele trei routere are in RIB / FIB Loopback-ul celorlalte doua, iar pe R1 avem configurat host pentru R3:
R1(config)# ip host R3 3.3.3.3
Daca fac telnet de pe R1 (sursa Loopback 0) pe R3 folosindu-ma de host-ul lui R3 (R1# telnet R3) si NU ma pot conecta din cauza ca:
1. toate “VTY lines” sunt ocupate
2. am configurat pentru VTY “(config-line)# access-class ACL in”, iar ACL-ul nu permite Loopback 0 al lui R1
3. am configurat un ACL direct pe interfata lui R3 (inbound) catre R2 care de asemenea nu permite Loopback 0 al lui R1
etc …
voi primi mesajul % Connection refused by remote host.
Ca sa customizez acest mesaj pot folosi comanda “busy-message” pe R1 (adica pe routerul de pe care fac telnet).
R1(config)#busy-message R3 # Enter TEXT message. End with the character '#' Nu te poti conecta pe R3 in acest moment ! #
R1# telnet R3 Translating "R3" Nu te poti conecta pe R3 in acest moment ! R1#
Aceasta comanda functioneaza doar daca la primul [SYN] trimis de R1 NU se primeste ca raspuns un pachet de tip [SYN, ACK]; adica raspunsul este fie [RST, ACK], fie un ICMP Destination Unreachable, fie nici un raspuns daca avem setat pe interfata cu ACL “no ip unreachables”, etc.
Asadar exista cazuri in care desi NU va puteti conecta prin telnet de pe R1 pe R3, NU veti primi mesajul setat cu “busy-message” pentru ca primul pachet primitcde la R3 este de tip [SYN, ACK]:
1. daca pe R3 nu este setata parola de VTY (Password required, but none set“)
2. daca pe R3 avem configurat pentru VTY “(config-line)# no exec”
etc.
Sa consideram acum ca ne aflam intr-unul din cazurile in care NU ne putem conecta de pe R1 pe R3 (toate VTY lines sunt ocupate pe R3) si primim mesajul setat cu “busy-message” pe R1. Ce putem configura pe R2 astfel incat sa nu ne mai apara acest mesaj pe R1 cand facem R1#telnet R3 ?
ATENTIE ! – nu avem voie sa umblam la config pe R1 si R3, doar pe R2.
pun in shut pe R2 interfata catre R3;
meserie.
Alin, din pacate lucrurile sunt un pic mai complicate decat atat. Daca pui in SHUT interfata de pe R2 catre R3, R1 nu o sa primeasca [SYN, ACK] de la nimeni cand face telnet pe R3 si dupa cateva secunde tot o sa-ti intoarca mesajul setat cu comanda “busy-message”. Multumesc pentru raspuns, intrebarea insa ramane deschisa.
ma gandeam sa schimb ip lo0 r2 cu lo0 r3, astfel r2 trimite SYN si nu mai apare mesajul “busy-message”
Ionut, intr-un fel solutia ta “face match” pe cerintele problemei … adica NU te conectezi la R3 (pentru ca practic te conectezi la R2 daca schimbi IP-ul) dar nici nu primesti mesajul setat cu comanda “busy-message”. Din pacate ai “trunchiat” un pic ipoteza, pentru ca pe tine nici nu te mai intereseaza practic daca pe R3 toate “VTY lines” sunt ocupate.
Incearca sa te gandesti la o modalitate prin care R1 sa primeasca un [SYN, ACK] de la loopback-ul lui R3 fara ca sesiunea TCP dintre R1 si R3 sa se poata stabili. In felul asta NU primesti nici “bussy-message” si nici nu te poti conecta pe R3.
Daca R1 primeste [syn, ack] dar sesiunea tcp nu se stabileste atunci ne aflam in cazul unei sesiuni tcp half-open, R1 trimite syn, R3 trimite [syn,ack] insa R1 nu trimite catre R3 ack, sau trimite dar ack-ul nu ajunge.
Daca nu exista un vty disponibil, R3 trimte direct [ack,rst], iar daca acest mesaj ajunge la R1, sau nimic nu ajunge, busy-message tot va fi afisat
Daca incerci sa sugerezi ca nu exista solutie la problema, atunci concluzia la care ai ajuns este gresita desi rationamentul tau din observatia anterioara este foarte corect (pana la concluzie). Intrebarea ramane deschisa !
initial am incercat pe R2 cu un named extended acl input pe interfata inspre R3:
ip access-list extended filter
deny tcp any eq telnet any match-all +ack +rst
permit ip any any
astfel R1 trimitea syn catre R3, iar [rst,ack] dinspre R3 nu mai ajungea la R1, dar dupa un timp desigur conexiunea tcp expira si mesajul busy-message aparea.
atunci am inteles ca R2 trebuie sa faca mai mult decat sa forwardeze pachetele dintre R1 si R3 si trebuie sa intermedieze sesiunea tcp/23 dintre R1 si R3, astfel pe R2 am configurat:
access-list 101 permit tcp any host 3.3.3.3 eq telnet
ip tcp intercept list 101
ip tcp intercept mode intercept (default in 12.4(24)T1, nu apare la show run)
acum R2 intercepteaza syn pentru sesiunea tcp care face match pe acl 101. R2 va incerca cate o noua conexiune, atat pe server cat si pe client, jucand pe rand rolul clientului si al server-ului. la final R2 “leaga” cele doua conexiuni astfel incat R1 sa poata comunica direct cu R3.
dupa “no ip route-cache” pe interfetele R2 (pentru a vedea pck tcp transit), facem “debug ip tcp intercept”:
*May 27 15:25:36.079: INTERCEPT: new connection (192.168.0.1:37621 SYN -> 3.3.3.3:23)
*May 27 15:25:36.087: INTERCEPT(*): (192.168.0.1:37621 3.3.3.3:23)
*May 27 15:25:36.135: INTERCEPT(*): (192.168.0.1:37621 SYN -> 3.3.3.3:23)
*May 27 15:25:36.151: INTERCEPT: in synsent (192.168.0.1:37621 <- RST 3.3.3.3:23)
*May 27 15:25:36.155: INTERCEPT(*): (192.168.0.1:37621 <- RST 3.3.3.3:23)
ce este important pentru noi este ca R1 va primi [ack,syn] de la R2, insa cu adresa ip a R3:
*May 27 15:33:39.431: IP: s=3.3.3.3 (GigabitEthernet1/0), d=192.168.0.1, len 40, TCP src=23, dst=18632, seq=247175282, ack=4126048114, win=0 ACK SYN
si astfel nu va mai afisa busy-message
aceasta este raspunsul corect, felicitari !
in sfarsit, m-a tinut pe jar de azi dimineata 😀 felicitari pentru intrebare, pentru mine a fost cea mai interesanta de pana acum!