Azure-VM, joka ajaa VPN-laitetta, sijaitsee kahden itsenäisen päätöksentekojärjestelmän sisällä. Azure päättää, mistä paketti lähtee aliverkosta, käyttäen reititystauluja ja verkkokortin edelleenlähetysasetusta. Laitteen oma käyttöjärjestelmä päättää, välittääkö se salatun paketin eteenpäin. Täydellisesti nouseva tunneli voi silti epäonnistua toisessa järjestelmässä, ja siihen useimmat näistä käyttöönotoista pysähtyvät.

Yhden polun kolme omistajaa

Ota haarverkko 192.168.50.0/24 ja työkuorman aliverkko 10.0.10.0/24, laite osoitteessa 10.0.0.4 omassa aliverkossaan. Yksi pyyntö koskettaa kolmea erillistä kokoonpanoa.

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

Jokaista riviä hallinnoi useimmissa organisaatioissa eri tiimi, minkä vuoksi tämä vika saapuu yleensä kolmena tikkettinä yhden sijaan.

Reitti, joka osoittaa laitteeseen

Liitä reititystaulu työkuorman aliverkkoon ja anna haaran etuliitteelle seuraava hyppy tyyppiä Virtual appliance kanssa 10.0.0.4 osoitteena. Käytä laitteen saavutettavaa yksityistä osoitetta, älä koskaan sen julkista VPN-sisääntulopistettä. Seuraavan hypyn on oltava osoite, johon työkuorman aliverkko jo pääsee. Jätä muu työkuorman reititys rauhaan, ellet ole tietoisesti päättänyt korvata oletusreittiä.

Pidä laite omassa aliverkossaan ja varmista, ettei reitti, joka lähettää haaran liikennettä laitteelle, nappaa myös laitteen omaa lähtevää polkua. Tällainen silmukka näyttää terveeltä tunnelilta ilman vastauksia, ja sitä on hyvin ikävä debugata kello 2 yöllä.

Verkkokortin lippu, jonka kaikki unohtavat

Azurella on IP-edelleenlähetysasetus jokaista verkkokorttia kohti, ja se on oletuksena pois päältä. Se on olemassa, koska edelleenlähettävä kortti vastaanottaa paketteja, jotka on osoitettu jollekin muulle, ja niiden hiljainen pudottaminen on turvallinen oletus kaikille muille.

az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true kytkee sen päälle yhdelle liitännälle. Microsoftin ohjeet verkkokortin edelleenlähetyksestä vaativat asetuksen jokaisella liitetyllä kortilla, joka välittää liikennettä, joten yhden kortin laite tarvitsee sen silti kyseisellä kortilla.

Lippu ei ole reitti eikä palomuurisääntö. Sen kytkeminen päälle antaa luvan eikä mitään muuta.

Mitä vieras tekee salatulla paketilla

Kun tunneli päättyy, laitteen oma pino tekee seuraavan päätöksen. Linux-vieraassa IPv4-edelleenlähetys on ajonaikainen asetus, ja sysctl -w net.ipv4.ip_forward=1 kestää seuraavaan käynnistykseen. Tallenna se sen sijaan tiedostoon /etc/sysctl.d/ kohdassa. Myyjän laitteella on oma vastineensa, ja myyjän alustaan liitetyt Linux-ohjeet eivät yleensä tee yhtään mitään.

Vieraan palomuurikäytäntö on jälleen erillinen, samoin työkuorman verkon suojausryhmä. UDP 500 ja 4500 salliminen VM:n julkiseen osoitteeseen suojaa tunnelia; se ei kerro mitään siitä, voiko salattu haarapyyntö päästä työkuorman porttiin.

Seuraa yhtä pyyntöä ja sen vastausta

Valitse yksi sallittu vuo ja seuraa sitä päästä päähän. Haara tarvitsee reitin 10.0.10.0/24 sivustoyhteyden yli, laite tarvitsee toimituspolun työkuorman aliverkkoon, ja työkuorman aliverkko tarvitsee paluureitin haaraan päin.

Päätä varhain, säilyttääkö suunnittelu haaran lähdeosoitteen vai kääntääkö se sen. NAT muuttaa sitä, mitä työkuorma näkee, joten sen käyttösääntöjen tulisi kuvata valitsemasi malli eikä arvattua yhdyskäytävän osoitetta.

Onnistunut kättely todistaa yhden lenkin tuosta ketjusta. Polku on valmis, kun vastaus palaa saman laitteen kautta ja työkuorman oma käytäntö sallii sen.

Aiheeseen liittyvät artikkelit