Wie antwoordt er eigenlijk op het toegewezen adres van de VPN?

Een adres dat ongebruikt in de toewijzing van de organisatie ligt, is geen luisteraar, en het aan een firewall toevoegen maakt er geen een. Iets moet IKE op dat adres beëindigen, en het mechanisme verschilt al naargelang de gateway het adres bezit of een upstream-apparaat het vertaalt. Het pakketpad is wat de twee onderscheidt, en het bepaalt welke platformfunctie u nodig hebt voordat iemand een wijzigingsverzoek opent. Modelleer eerst het pad en kies dan.

Het pakketpad achter het adres

Een peer stuurt IKE naar het adres dat hij heeft gekregen, op UDP 500 of op UDP 4500 wanneer NAT-traversal meespeelt. Welk apparaat dat adres op het pad ook bezit, het ontvangt het datagram lokaal en beantwoordt het, of het stuurt het elders heen. Dat zijn de enige twee mogelijkheden, en al het overige in dit artikel volgt uit welke waar is.

Lokaal ontvangen betekent dat er op dat apparaat een socket bestaat, gebonden aan dat adres. Doorsturen betekent dat het datagram wordt herschreven en verder wordt gestuurd naar een ander eindpunt, dat dan de socket heeft. Een firewallregel die UDP 500 toestaat, zegt u niets over welke van de twee gebeurt.

Schrijf het record voordat u iets aanraakt: het adres dat peers contacteren, hoe het upstream-netwerk het levert, de lokale interface of het logische eindpunt dat het ontvangt, en het proces dat IKE beantwoordt. Vier regels, en elk ervan is te controleren. Wanneer een ervan onbekend is, is dat onbekende het ontwerpwerk en niet een implementatiedetail dat later wordt beslecht. Ze invullen nadat het wijzigingsverzoek is goedgekeurd, is hoe een vertaalregel op het verkeerde apparaat belandt.

Model A: de gateway bezit het adres

In het eerste model houdt de gateway het adres zelf, hetzij als secundair adres op een bestaande interface, als adres op een toegewijde interface, of als loopback die het platform als tunneleindpunt ondersteunt. Dat zijn drie verschillende functies met drie verschillende configuratiepaden, en een platform dat er één ondersteunt, ondersteunt misschien de andere niet.

Bevestig dat het platform en de release precies deze opstelling ondersteunen voordat u eromheen ontwerpt. Een gerouteerd blok, een extra adres op een interface en een loopback-eindpunt zijn niet uitwisselbaar, en de documentatie van de ene release belooft niet dat de volgende zich hetzelfde gedraagt.

ip -br addr show
ss -lunp | grep -E ':500|:4500'
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'

De luisterende socket is het bewijs. Als er niets aan het adres is gebonden, is de gateway niet de terminator wat de routetabel ook zegt, en een pakketopname toont de datagrammen aankomen zonder dat iets ze beantwoordt.

Plaats geen tweede interface in een subnet dat elders in de topologie al bestaat en ga er niet van uit dat het platform dat oplost. Overlappende interface-subnetten geven een dubbelzinnige bronkeuze en, op veel platforms, een botte weigering om te configureren.

Model B: een upstream-apparaat vertaalt het

In het tweede model bezit een upstream-firewall het toegewezen adres en stuurt het verkeer door naar een andere VPN-gateway. Dat is een bestemmingsvertaling met een retourpad, en het is een volkomen geldig ontwerp zolang het als zodanig gedocumenteerd is.

Wat het niet is, is bewijs dat het upstream-apparaat een lokale VPN-socket heeft verkregen. De vertaling stuurt pakketten door; ze maakt van de bovenste doos geen IKE-responder. Als de upstream-regel wordt verwijderd of het retourpad breekt, stopt de VPN ook al is de gateway gezond en zijn eigen luisteraars intact.

Registreer beide adressen: het adres dat peers contacteren en het adres dat de gateway werkelijk ziet. Registreer daarna het transport en het retourpad, want een vertaling die werkt voor UDP 500 maar niet voor ingekapselde ESP, maakt verbinding en kan daarna geen verkeer dragen, wat een verwarrende fout is om later te debuggen.

Identiteit is niet het buitenadres

IPsec scheidt het tunneleindpunt van het verkeer dat het beschermt, en de architectuur houdt die beslissingen op verschillende plaatsen. Het adres wijzigen dat peers contacteren, wijzigt niet automatisch welke binnenste prefixen zijn toegestaan, welke routes worden geïnstalleerd of welke bronnen de sessie kan bereiken.

De geauthenticeerde identiteit staat weer apart. IKEv2 draagt een identiteitspayload en een authenticatie-uitwisseling die niet hoeven overeen te komen met het buitenste pakketadres, en juist daarom kan een vertaald ontwerp nog steeds correct authenticeren.

Die onafhankelijkheid is nuttig en tegelijk een valkuil. Twee DNS-namen die naar één gewone luisteraar verwijzen, kiezen geen verschillende VPN-backends, en een certificaat dat één identiteit noemt, zal een peer die een andere verwacht niet tevredenstellen. Bevestig wat de peer valideert voordat u aanneemt dat het adres alleen dat bepaalt.

Accepteer het ontwerp door één verbinding te observeren

Onderzoek waar een nieuwe geautoriseerde verbinding werkelijk wordt afgeleverd, welke identiteit antwoordt en welke privéstroom daarna is toegestaan. Drie observaties, drie verschillende lagen, en een geslaagde openbare opzoeking van het adres test geen ervan.

Houd ook het negatieve geval aan: een peer die niet mag worden geaccepteerd, of een binnenste prefix dat niet bereikbaar mag zijn, na de wijziging geverifieerd. Het record dat u in het begin schreef, is wat die test mogelijk maakt zonder het ontwerp uit het geheugen te reconstrueren.

De bedoeling van dit alles is de netwerkeigenaar een ondersteunde toewijzingsmethode te laten kiezen in plaats van te vertrouwen op een algemene bewering over wat elke firewall met een extra adres kan doen. Die bewering is precies het punt waar deze ontwerpen misgaan, omdat ze op elk platform plausibel klinkt en in het algemeen op geen enkele klopt. Het record van vier regels beslecht het voor uw platform in tien minuten.