VPN-adapter toont /32: dat betekent niet één bestemming
Een masker van 255.255.255.255 op een VPN-adapter is het adres van de client zelf, geen grens voor bereikbare hosts. Lees routes, gateway-bereik en retourpad apart.
Adapters tonen 255.255.255.255, en vaak luidt de conclusie dat de VPN precies één adres bereikt. Die lezing verwart het eigen adres van de client met de verzameling bestemmingen die via de tunnel worden gerouteerd. Op een point-to-point- of gerouteerde interface zijn dat twee verschillende objecten, en slechts één ervan beperkt de bereikbaarheid. De mythe blijft bestaan omdat het masker lijkt op het subnetmasker dat mensen op Ethernet hebben geleerd.
De mythe: een hostmasker betekent één bereikbare host
Een /32-toewijzing vertelt de interface welk adres bij dit uiteinde van de verbinding hoort, en op een point-to-point-verbinding is dat alles wat het betekent. Het adres van de peer is een apart veld, en de routes die vertellen wat er achter de peer ligt, zijn opnieuw apart. Niets in het masker beschrijft het externe netwerk, omdat het masker niet de plek is waar externe netwerken worden beschreven. Het lezen als bereikbaarheidsgrens is als je eigen huisnummer lezen als een lijst van alle adressen die je mag bezoeken.
De verwarring heeft een echte wortel: op Ethernet zou een hostmasker echt één adres op dat segment betekenen. Een tunnel is geen Ethernet-segment, en wat erdoorheen gaat bepaalt de routetabel van de client, niet het masker. Daarom kan hetzelfde /32 voor een heel datacenter staan.
Lees het adres en de routes als afzonderlijke objecten
Druk de interface en de tabel samen af en lees ze daarna als twee antwoorden op twee vragen. Het adres beantwoordt wie dit uiteinde is; de routes beantwoorden waar het verkeer heen mag. Een derde vraag, welke bestemmingen de gateway toestaat, is op de client helemaal niet zichtbaar. De adresreferentie van iproute2 beschrijft de velden voor lokaal adres, peer en prefixroute juist daarom apart.
ip addr show tun0
ip route show
ip route get 10.60.5.10
Op Windows bestaat dezelfde splitsing tussen de adressenlijst en de routetabel, en de opzoekopdracht is de snelste manier om te zien welke wint voor een bepaalde bestemming. Als de opzoeking de tunnelinterface teruggeeft, stuurt de client het pakket daarheen. Als zij de fysieke adapter teruggeeft, vraagt de client nooit aan de VPN, en geen enkele machtiging aan de serverkant verandert dat. Controleer de bestemming die je echt nodig hebt, niet een algemeen openbaar adres.
Get-NetIPAddress -InterfaceAlias "VPN"
Find-NetRoute -RemoteIPAddress 10.60.5.10
Stop als de opzoeking naar de verkeerde interface wijst. Dat is een routeringsprobleem van de client, en het wordt op de client opgelost.
Waarom een breder masker het meestal erger maakt
De toewijzing naar een /24 veranderen zodat het op het kantoor-LAN lijkt, kan een prefix op de verbinding maken: de kernel gelooft nu dat het hele /24 rechtstreeks aan de tunnelinterface hangt. Verkeer naar adressen die via de gateway gerouteerd zouden moeten worden, wordt dan verzonden alsof er een buur op de verbinding zit. Het resultaat is een zwart gat dat op een serverstoring lijkt.
Het verbergt ook het echte probleem, namelijk een ontbrekende route of een ontbrekende machtiging op de gateway. Geen van beide wordt door een breder masker gemaakt, en beide overleven de wijziging. Als het ontwerp een grotere prefix op de interface nodig heeft, is dat een beslissing voor het gebruikte interfacemodel, genomen met de documentatie in de hand. Een masker kopiëren uit de schermafbeeldingen van een ander product is die beslissing niet.
Als de route van de externe prefix ontbreekt, herstel dan de provisioning ervan. Als die aanwezig is en de verbinding nog steeds wordt geweigerd, was het masker nooit de diagnose.
Wanneer de route klopt en de stroom toch faalt
Een correcte route bewijst alleen dat de client het pakket zal versturen. De gateway moet de bestemming nog steeds accepteren, het retourpad moet bestaan voor het toegewezen adres, en de dienst moet de stroom toestaan. Test die drie apart: de opzoeking op de client, het toegestane bereik van de gateway en een verzoek aan één benodigde server. Dat de authenticatie slaagt voordat alle drie op hun plaats zijn, is normaal, en daarom kan een verbonden client toch niets bereiken.
ping -c1 10.60.5.10
traceroute -n 10.60.5.10
curl -sv https://app.internal.example/ -o /dev/null
Houd netwerkobjecten en groepsrechten bij hun eigenaar op een door een apparaat beheerde dienst. Wat de client wordt geacht te bereiken en wat hij mag gebruiken zijn verschillende instellingen, vaak op verschillende schermen. Het ene wijzigen en het andere testen is hoe een ticket tussen twee teams heen en weer springt.
De mythe die met pensioen moet, is dat het masker een bereikbaarheidsgrens is. Lees het adres, de routes en het gateway-beleid als drie afzonderlijke feiten, en een /32 ziet er niet langer uit als een beperking en begint eruit te zien als een normale tunneltoewijzing.