Eén /24 voor een laboratoriumprinter verdwijnt tussen twee ip route show-aanroepen, en het clientlog zegt alleen dat het netwerk is veranderd. Er was niets mis met het commando, het prefix of uw rechten. Een zakelijke client die het routingmodel van de host bezit, bevestigt dat model opnieuw telkens wanneer iemand anders het bewerkt, dus de vermelding die u toevoegde wordt als indringer verwijderd. Ertegen vechten in dezelfde tabel is een verloren positie. De oplossing is helemaal stoppen met concurreren om die tabel en de uitzondering plaatsen waar de monitor nooit kijkt.

De monitor verklaart de ontbrekende route

Demonstreer het voordat u iets herontwerpt: lees de tabel, voeg het prefix toe, wacht een paar seconden, lees opnieuw. Als de vermelding ontbreekt en u hebt niets getypt om hem te verwijderen, houdt een agent toezicht. Zoek het proces dat dat gedrag bezit en lees zijn journaal rond het moment waarop de route verdwijnt, want dezelfde dienst onderhoudt meestal de tunnel, de packetfilters en de resolverconfiguratie. Hem doden om uw route te laten staan is een ruil waarvan u bij de volgende herverbinding spijt krijgt.

ip route show
ip route add 192.168.2.0/24 dev enp0s31f6
sleep 5; ip route show

Het prefix en de interface hierboven zijn plaatsaanduidingen. Een interfacenaam kopiëren uit een werkend voorbeeld op een andere machine is de meest voorkomende reden waarom deze demonstratie helemaal niets oplevert.

Een tweede tabel is onzichtbaar voor de monitor

De agent herbouwt alleen de tabel die hij bezit. Geef de uitzondering een eigen tabel plus een regel die overeenkomende bestemmingen daarheen stuurt, en de hoofdtabel verandert nooit, dus de agent heeft niets te corrigeren. Dat is het hele idee: één naamruimte van routes die iemand anders onderhoudt, en één die alleen u aanraakt.

De ruil is onderhoud. Twee objecten kunnen uit elkaar lopen, en de positie van de regel in de lijst is net zo belangrijk als de route in de tabel die hij selecteert.

Bouw de uitzondering en laat hem dan winnen

Maak de tabel, installeer de route en voeg een regel toe die de tabel voor die bestemming selecteert. De prioriteit bepaalt of uw regel vóór of na de regels van de client wordt geraadpleegd, en een regel die later sorteert wordt nooit bereikt, dus het nummer is onderdeel van het ontwerp en geen decoratie. Vraag daarna aan de kernel wat hij werkelijk zou doen, wat een andere vraag is dan wat u hebt geconfigureerd.

ip rule add to 192.168.2.0/24 table 110 pref 30010
ip route add 192.168.2.0/24 dev enp0s31f6 table 110
ip route get 192.168.2.50

ip route get lost de route op die de kernel zou gebruiken, inclusief het apparaat en het bronadres. Het drukt de tabelidentificatie niet af, dus combineer het met ip rule show wanneer u moet bevestigen welke tabel heeft gewonnen. Samen beantwoorden ze de enige vraag die ertoe doet: verlaat het verkeer naar dat adres de plek die u bedoelde?

Andere vormen van hetzelfde idee

Het patroon generaliseert zodra u ophoudt in bestemmingen te denken. Een lokaal subnet kan bereikbaar blijven terwijl de tunnel de standaardroute houdt. Antwoorden van een SSH-server op de LAN kunnen uitgaan via de interface waarop ze binnenkwamen in plaats van in de tunnel te verdwijnen. En een op interfaces gebaseerde regel kan alles wat op een draadloze interface binnenkomt de tunnel in duwen, terwijl verkeer dat de host zelf genereert op Ethernet blijft:

ip rule add iif wlan0 table 10
ip route add default dev tun0 table 10

Dat laatste geval komt overeen met de inkomende interface in plaats van de bestemming, wat een ander regeltype en een ander mentaal model is. Doorgestuurd verkeer vereist ook ingeschakelde net.ipv4.ip_forward, en de verre kant moet het bronbereik terug routeren of vertalen; een regel op één machine creëert nooit de andere helft van het pad.

Behandel de regel als wegwerpmateriaal

Regels en tabelroutes leven in het geheugen. Na een herverbinding kan het tunnelapparaat worden hernoemd, het toegewezen adres kan verschuiven, en een regel met de oude waarde stopt stilzwijgend met matchen. Pas de hele wijziging opnieuw toe vanuit één script dat hem bezit, en controleer daarna ip rule show, de huidige apparaatnaam en een verse ip route get tegen een echte bestemming voordat u de uitzondering vertrouwt.

Twee grenzen overleven elke zorgvuldigheid. De client beheert nog steeds zijn eigen filterregels en de resolverconfiguratie, en een routing-uitzondering overrulet geen van beide. Als de client ook uw beleidsregel verwijdert, zijn de ondersteunde paden zijn eigen split-tunnelbeleid of een client die u routes laat beheren, zoals OpenConnect; een binair bestand van een leverancier patchen om zijn monitor het zwijgen op te leggen is een onderhoudsverplichting met een integriteitscontrole eraan vast.

Schrijf het tabelnummer, de prioriteit en de bestemming in een notitie naast het script. Anders vindt de volgende persoon een regel die de tunnel overstemt en heeft geen manier om te weten waarom.

Gerelateerde artikelen