Overzicht #
Dit artikel legt uit hoe u deze problemen kunt identificeren en oplossen. asymmetrische routeringsproblemen een RELIANOID Implementatie wanneer de load balancer meerdere netwerkinterfaces heeft die verbonden zijn met verschillende subnetten.
Deze situatie kan zich voordoen wanneer frontend-clients toegang moeten hebben tot backend-services die zich in een ander subnet bevinden, terwijl de load balancer interfaces in beide netwerken heeft.
Onjuist routeringsgedrag kan ertoe leiden dat antwoordverkeer via een andere interface wordt verzonden dan de interface die voor het inkomende verzoek is gebruikt, wat resulteert in asymmetrische routering.
Beschrijving van het probleem #
In sommige implementaties, de RELIANOID De load balancer is geconfigureerd met meerdere interfaces die verbonden zijn met verschillende netwerken.
De volgende configuratie is een voorbeeldomgeving die voor demonstratiedoeleinden wordt gebruikt.
| Interface | Netwerk | Doel |
| eth0 | 192.168.1.0/24 | Management |
| eth1 | 192.168.110.0/24 | Frontend |
| eth2 | 192.168.100.0/24 | Applicatie / Backend |
De backendservers bevinden zich in het subnet 192.168.100.0/24 en zijn toegankelijk via farms die geconfigureerd zijn op de load balancer.
Sommige klanten in het 192.168.110.0/24-netwerk moeten echter ook toegang hebben tot diensten die worden gehost in het 192.168.100.0/24-netwerk.
Omdat de load balancer een interface in beide netwerken heeft en IP-forwarding standaard is ingeschakeld, kan het systeem responsverkeer rechtstreeks via de frontend-interface (eth1) routeren in plaats van via de verwachte gateway.
Dit resulteert in asymmetrische routering , wat kan leiden tot verbindingsproblemen of het verlies van datapakketten.
Voorbeeld interfaceconfiguratie #
Wat is asymmetrische routering? #
Asymmetrische routering treedt op wanneer het inkomende en uitgaande verkeer van dezelfde verbinding verschillende netwerkpaden volgt.
Voorbeeldstroom #
Bestemmingspad: 192.168.110.11 via eth2 (Client) > 192.168.100.100 (Load Balancer) > 192.168.100.42 (Backend)
Retourpad (onjuist): 192.168.100.42 (Backend) > 192.168.100.100 (Load Balancer) > 192.168.110.11 via eth1 (Client)
Omdat het retourverkeer via een andere interface vertrekt, kunnen tussenliggende apparaten zoals firewalls of routers de pakketten blokkeren.
Hoe routeringstabellen werken #
RELIANOID toepassingen routeringstabellen per interface om te bepalen hoe verkeer tussen netwerken wordt doorgestuurd.
Elke interface genereert automatisch zijn eigen routeringstabel.
Voorbeelden van routeringstabellen: table_eth1, table_eth2
Deze routeringstabellen definiëren:
- Routes die aan de interface zijn gekoppeld
- Gateways die worden gebruikt voor het doorsturen van verkeer.
- Interfaces die het mogelijk maken om verkeer door te sturen
Binnen elke routeringstabel kunnen interfaces als volgt worden geconfigureerd:
Beheerde interfaces #
Interfaces die het verkeer binnen de routeringstabel mogen routeren met behulp van de IP-forwardingfunctie.
Niet-beheerde interfaces #
Interfaces die zijn uitgesloten van routeringsbeslissingen voor die tabel en waarvoor IP-forwarding niet van toepassing is, worden niet doorgevoerd.
Door te bepalen welke interfaces beheerd of niet-beheerd zijn, kunnen beheerders de verkeersstroom door de load balancer beïnvloeden en routeringsconflicten voorkomen.
Voorbeeld routeringstabel #
Het resultaat #
Om het probleem van asymmetrische routering op te lossen, moet de conflicterende interface worden uitgesloten van de routeringstabel die is gekoppeld aan het backend-netwerk.
In dit scenario, eth1 moet uit de routeringstabel worden verwijderd. table_eth2waardoor het verkeer via de juiste gateway wordt geleid.
Oplossing via de webinterface #
- Ga naar: Netwerk > Routering
- Selecteer de routeringstabel die is gekoppeld aan de backend-interface:
table_eth2 - Scroll naar de onderkant van de pagina.
- Zoek de Beheerde interfaces pagina.
- Verplaats de interface eth1 vanaf Beheerde interfaces naar Niet-beheerde interfaces.
Dit voorkomt dat verkeer rechtstreeks via de frontend-interface wordt gerouteerd wanneer de backend-routeringstabel wordt gebruikt.
Oplossing via de CLI #
Dezelfde configuratie kan ook worden toegepast met behulp van de RELIANOID KLI.
Stap 1: API-toegang inschakelen #
Ga naar: Systeem > Gebruikersinstellingen
Schakel API-toegang in en configureer een API-sleutel. U kunt uw eigen sleutel definiëren of een willekeurige sleutel genereren.
Nadat je de sleutel hebt aangemaakt, kopieer en bewaar je deze, want je hebt hem nodig de eerste keer dat je de CLI gebruikt met noid-cli.
Stap 2: toegang RELIANOID CLI #
Voer vanuit de systeemconsole het volgende commando uit:
noid-cli
Voer de API-sleutel in wanneer daarom wordt gevraagd.
Stap 3: Interface verwijderen uit de routeringstabel #
Voer de volgende opdracht uit:
network-routing-table-unmanaged add table_eth2 -interface eth1
Deze opdracht voorkomt dat verkeer wordt omgeleid via eth1 bij gebruik van de routeringstabel table_eth2.
Stap 4: De configuratie terugzetten (optioneel) #
Indien nodig kan de configuratie met het volgende commando worden teruggezet:
network-routing-table-unmanaged remove table_eth2 eth1
Best Practices #
- Voer routewijzigingen uit tijdens Rustige uren of onderhoudsperiodes.
- Controleer de verbinding na het toepassen van de configuratie.
- Zorg ervoor dat andere diensten niet worden beïnvloed door wijzigingen in de routering.
Conclusie #
Asymmetrische routeringsproblemen kunnen optreden wanneer een load balancer is verbonden met meerdere netwerken en het verkeer via een andere interface terugkeert dan de interface die voor de inkomende verbinding is gebruikt.
In RELIANOIDDit probleem kan worden opgelost door de configuratie van de routeringstabellen aan te passen en conflicterende interfaces uit specifieke routeringstabellen te verwijderen.
Dit zorgt ervoor dat het verkeer het juiste netwerkpad volgt en voorkomt verbindingsproblemen.
