[GTER] Dúvida: ativar serviços no LoopBack

[Wladimir Pereira]

continuando...

Se a interface em B que possui o endereço IP de destino da conexão estiver
DOWN, o serviço cai, mesmo que os dois roteadores tenham alcançabilidade.


"O que impede de aparecer num trace route? Caso a resposta seja um tanto
off, uma referência já me basta :)"

Traceroute percorre equipamentos utilizando suas sub-redes comuns entre si.
Umm traceroute entre A e C, passando por B, você terá retorno dos endereços
IP configurados nas interfaces de ponto-a-ponto, mas nunca de um IP de
loopback utilizado para um serviço de peering BGP, por exemplo.
Alguns ataques com objetivo de derrubar sessões BGP geralmente ocorrem pela
tentativa de falsificar o IP de origem de uma interface entre um ponto
comum (operadora e cliente), contando com a possibilidade de que o peering
esteja ocorrendo com aqueles endereços (de interface física), que
geralmente são obtidos através de um traceroute.


"E por que ouço falar do uso de /32 para tal? É por que loopback não precisa
de broadcast, arp e tais elementos?"

Correto.
O uso de prefixo maior que /32 apenas desperdiçará endereços.



Abraços.




Em 22 de abril de 2014 15:42, Wladimir Pereira <wladnery at gmail.com>escreveu:

> "Então em um equipamento que não tem múltiplos caminhos, isso não faz muita
> diferença?"
>
> Correto.
> Mesmo assim, é bom considerar que a origem (ou destino) de uma solução
> pode mudar de endereço (literalmente).
> Supondo um cenário de roteadores A, B e C, onde a origem da conexão está
> em A, e o destino está em B, e que a origem agora passou a ser atendida em
> C, o tráfego entre origem (C) e destino (B) o pacote terá que atravessar o
> roteador B
>
>
> Em 22 de abril de 2014 15:28, Raimundo Santos <raitech at gmail.com>escreveu:
>
> 2014-04-22 15:01 GMT-03:00 Wladimir Pereira <wladnery at gmail.com>:
>>
>> > Um dos principais motivos de se utilizar interfaces loopback para os
>> > serviços citados está no fato de que elas estarão sempre ativas. O
>> endereço
>> > IP configurado numa interface loopback estará sempre presente na tabela
>> de
>> > rotas de um determinado equipamento.
>> >
>>
>> Então em um equipamento que não tem múltiplos caminhos, isso não faz muita
>> diferença?
>>
>>
>> > Quando se utiliza um endereço IP de interface física, se o estado de
>> enlace
>> > desta vir a ficar DOWN, o endereço não mais estará na tabela de rotas do
>> > equipamento, derrubando o serviço VPN, por exemplo, mesmo que existam
>> > múltiplos caminhos entre origem e destino da solução.
>> >
>> > Nestes tipos de solução (OSPF, VPN, BGP, etc), quando há a necessidade
>> de
>> > se ter alcance externo, utilizam-se endereços IP publicáveis, que podem
>> ser
>> > aplicados nestas interfaces, e não apenas saber que o bloco 127/8,
>> > reservado para testes locais, as utilizam.
>> >
>>
>> Como o Wenderson Souza também citou, creio que boa parte da minha dúvida
>> se
>> esclareça lembrando que outros endereços, inclusive os globalmente
>> roteáveis, podem ser associados aos loopback devices.
>>
>> Porém, persiste uma dúvida: se todos os meus caminhos até chegar em tal
>> equipamento estiverem fora do ar, qual a vantag... opa! Acho que respondi
>> a
>> mim mesmo: se todos os caminhos ficarem down, por qualquer motivo que
>> seja,
>> então o equipamento está 'oficialmente' down, mesmo que em sua própria
>> tabela de roteamento ainda exista a entrada para o endereço na loopback.
>>
>>
>> > Sobre aplicação de peering eBGP com interfaces loopback, um dos
>> principais
>> > motivos de sua aplicação está na segurança. Peering BGP entre loopbacks
>> não
>> > aparecem em traceroute, evitando se tornarem alvos de ataques por
>> estarem
>> > "ocultos".
>> >
>>
>> O que impede de aparecer num trace route? Caso a resposta seja um tanto
>> off, uma referência já me basta :)
>>
>> E por que ouço falar do uso de /32 para tal? É por que loopback não
>> precisa
>> de broadcast, arp e tais elementos?
>>
>> Obrigado por seu tempo em responder, Wladimir. Creio que sua resposta
>> acabou resumindo e agrupando outras respostas.
>>
>> []s
>> Raimundo Santos
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>
>
>