’n Azure-VM wat ’n VPN-toestel huisves, staan binne twee onafhanklike besluitstelsels. Azure besluit waar ’n pakket ’n subnet verlaat, met behulp van roetetabelle en die NIC se aanstuurstelling. Die toestel se eie bedryfstelsel besluit of hy die ontsyferde pakket verder aanstuur. ’n Tonnel wat heeltemal reg opkom, kan steeds op die tweede stelsel misluk, en dit is waar die meeste van hierdie ontplooiings stop.

Drie eienaars van een pad

Neem ’n taknetwerk van 192.168.50.0/24 en ’n werkla-subnet van 10.0.10.0/24, met die toestel by 10.0.0.4 in sy eie subnet. Een enkele versoek raak drie afsonderlike konfigurasies.

DecisionConfigured inHow it fails
Where the workload subnet sends branch trafficAzure route table entryTraffic leaves the subnet and never reaches the appliance
Whether a NIC may accept traffic not addressed to itAzure NIC IP forwardingPackets arrive and disappear at the interface
Whether the guest forwards decrypted trafficGuest OS or vendor appliance policyTunnel is up, workload is unreachable
Whether the workload accepts the sourceNSG and service policyRequests delivered, replies refused

Elke ry word in die meeste organisasies deur ’n ander span besit, en daarom kom hierdie fout gewoonlik as drie kaartjies in plaas van een.

Die roete wat na die toestel wys

Koppel ’n roetetabel aan die werkla-subnet en gee die takvoorvoegsel ’n volgende sprong van die tipe Virtual appliance met 10.0.0.4 as die adres. Gebruik die toestel se bereikbare private adres, nooit sy openbare VPN-toegangspunt. Die volgende sprong moet ’n adres wees wat die werkla-subnet reeds kan bereik. Los die res van die werkla se roetering alleen, tensy jy doelbewus besluit het om die verstekroete te vervang.

Hou die toestel in sy eie subnet, en sorg dat die roete wat takverkeer na die toestel stuur nie ook die toestel se eie uitgaande pad vasvang nie. Daardie lus lyk soos ’n gesonde tonnel met nul antwoorde, wat ’n ellendige ding is om om 2 in die oggend te ontfout.

Die NIC-vlag wat almal vergeet

Azure het ’n IP-aanstuurstelling per NIC, en dit is by verstek af. Dit bestaan omdat ’n aansturende NIC pakkette ontvang wat aan iets anders as homself gerig is, en om dié stilweg te laat val is die veilige verstek vir almal anders.

az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true skakel dit vir een koppelvlak aan. Microsoft se NIC-aanstuurriglyne vereis die stelling op elke gekoppelde NIC wat verkeer aanstuur, dus ’n toestel met een NIC het dit steeds op daardie een NIC nodig.

Die vlag is nie ’n roete nie en dit is nie ’n vuurmuurreël nie. Om dit aan te skakel verleen toestemming en niks anders nie.

Wat die gas met die ontsyferde pakket doen

Sodra die tonnel eindig, neem die toestel se eie stok die volgende besluit. Op ’n Linux-gas is IPv4-aansturing ’n tydinstelling, en sysctl -w net.ipv4.ip_forward=1 duur tot die volgende herbegin. Maak dit permanent in ’n lêer onder /etc/sysctl.d/ in plaas daarvan. ’n Verkoperstoestel het sy eie ekwivalent, en Linux-instruksies wat op ’n verkoperplatform geplak word, doen gewoonlik heeltemal niks.

Gas-vuurmuurbeleid is weer apart, en so ook die werkla se netwerksekuriteitsgroep. Om UDP 500 en 4500 na die VM se openbare adres toe te laat, beskerm die tonnel; dit sê niks oor of ’n ontsyferde takversoek ’n werkla-poort mag bereik nie.

Volg een versoek en sy antwoord

Kies een toegelate vloei en spoor dit van begin tot end na. Die tak het ’n roete nodig vir 10.0.10.0/24 oor die terreinverbinding, die toestel het ’n afleweringspad na die werkla-subnet nodig, en die werkla-subnet het ’n terugroete na die tak nodig.

Besluit vroeg of die ontwerp die tak se bronadres bewaar of dit vertaal. NAT verander wat die werkla sien, so sy toegangsreëls moet die model beskryf wat jy werklik gekies het, eerder as ’n geraapte poortadres.

’n Suksesvolle handdruk bewys een skakel van daardie ketting. Die pad is volledig wanneer die antwoord deur dieselfde toestel terugkeer en die werkla se eie beleid dit toelaat.

Verwante artikels