Twa publike IP's op ien Azure VPN-VM: hokker docht wat

Twa publike IP's op ien Azure VPN-VM meitsje in ferwachting dy't selden hâldt: it adres dêr't klanten mei ferbine, is ek it adres dat websiden sjogge. Trije ûnôfhinklike besluten meitsje dat resultaat, en allinnich it earste giet oer de tunnelharker. It twadde is de boarne yn 'e gast dy't brûkt wurdt foar trochstjoerde klantferkear, en it tredde is de Azure-útgongsmethode dy't op dy boarne fan tapassing is. Feroarje ien en de oare twa bliuwe wêr't se wiene, dus beslis elk eksplisyt.

Beslissing 1: wêr't de tunnel einiget

In publike Azure-IP is keppele oan in partikuliere IP-konfiguraasje op 'e NIC; it is net in adres dat jo tafoegje yn it bestjoeringssysteem fan 'e gast. Lês de keppeling ynstee fan dy oan te nimmen: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. Hokker partikulier adres dat query ek weromjout, dat is it adres dat de gast eins hawwe moat.

Ien NIC kin ferskate IP-konfiguraasjes drage, dus twa publike adressen fereaskje net twa NIC's. As it ûntwerp wol twa NIC's brûkt, bringt elk syn eigen gastrûtes en folgjende hops mei, en dan hawwe jo in routingbeslissing tafoege ynstee fan ien te ferienfâldigjen.

Foar in tsjinst mei in eksplisite lokale bining, binigje oan it echte partikuliere adres fan 'e gast, nea oan 'e publike placeholder. In harker dy't alle adressen akseptearret, ûntfangt ferkear fia elke IP-konfiguraasje dy't him berikt, dus behein de yngong mei de netwurkfeiligingsgroep en de host-firewall ynstee fan te hoopjen dat de biningsoarder beslissend is.

Beslissing 2: hokker boarne de trochstjoerde klant brûkt

Nei't de gateway in klantfersyk ûntsifere hat, is it pakket dat er trochstjoert oars as it pakket dat by de VPN-harker oankaam. De gast hat trochstjoering ynskeakele nedich, in firewallbelied dat de stream tastean, en in boarneasdres dat it wolkûntwerp tastiet. As jo it ynterne klantadres oersette, is dat oersetten boarne wat Azure beoardielje sil, net it ynterne adres fan 'e klant.

In smelle SNAT-regel kin in partikuliere gastboarne kieze, mar kin in folgjende Azure-oersetting net oerwinnen. Kies SNAT as jo ferantwurdlikheid per klant binnen de VM nedich hawwe; slaan it oer as it útgongsûntwerp fan it subnet al in stabile publike boarne jout en in twadde oersetting allinnich steat tafoegje soe.

Beslissing 3: hokker Azure-útgongsmethode wint

Microsoft dokumintearretde foarrangoarder foar útgong: in tapaslike rûte nei in apparaat of gateway hat foarrang, en subnet-NAT Gateway-ferbining hat foarrang boppe in publike IP op ynstânsnivo op it oangeande paad. Dy oarder is de reden dat oersetting nei 10.20.0.5 net bewiist dat in webside 198.51.100.20 sjen sil. Lês de effektive rûtetabel, de NAT Gateway-keppeling en de publike IP fan 'e NIC tegearre foardat jo it útgongsûntwerp akseptearje.

Hâldde trochstjoeringsynstelling fan 'e Azure-NICapart fan trochstjoering yn Linux. De wolkflag stiet pakketten ta wêrfan't de boarne of bestimming net oan 'e NIC tawiisd is; it skeakelet net.ipv4.ip_forward net yn, en de ynstelling fan 'e gast jout gjin wolktaastimming.

De tunnelsocket hat syn eigen boarnebeslissing

WireGuard syn Address ûnder wg-quick jout in adres oan 'e WireGuard-ynterface; it is gjin ynstruksje foar eksterne UDP-bining. De boarne fan 'e fersifersoke socket folget de rûtetabel, dus in beliedsrûte of in twadde standertrûte kin it ferpleatse sûnder it ynterface-adres oan te reitsjen.OpenVPN: de opsje local en UDP multihome gedrage har itselde: se geane oer de harker en syn antwurden, net oer de ynternetboarne fan elke trochstjoerde klant.

Bewarje de ûnderlizzende rûte dy't de tunnel draacht, en befêstigje dat de klant noch autentisearre antwurden fan 'e ferwachte yngongsregeling krijt. Fertrou net op de oarder fan 'e adreslist as in permanint belied foar boarnekar, want it folgjende adres dat oan 'e NIC tafoege wurdt, kin feroarje hokker wint.

Wat te akseptearjen, en yn hokker oarder

Akseptearje trije resultaten apart. Earst berikt in eksterne klant de bedoelde VPN-yngong. Twad, in nij tastien fersyk fan dy VPN-klant ferlit fia de dokumintearre ynternetútgong. Tred, net-bedoelde harker- en trochstjoeringspaden bliuwe wegere. Registrearje de publike-nei-partikuliere keppelingen en de gast- en wolk-eigeners fan elk beslissing op itselde plak.

In suksesfolle tunnel bewiist allinnich it earste part. Test de útgong mei in nije stream, want in cachele ferbining kin de âlde boarne noch lang nei de rûteferoaring brûke.