Yksi NIC vai kaksi? Näin valitset VPN-palvelimen liitäntärakenteen

Yksi fyysinen sovitin riittää moneen VPN-palvelimeen, eikä sekään ole yleispätevä rakenne. Salattu yhteys saapuu sille sovittimelle, VPN-prosessi purkaa sen salauksen, ja sisempi liikenne lähtee virtuaaliliitännän kautta ennen kuin se saavuttaa paikallisen palvelun tai reititetyn LANin. Toimiiko se, riippuu kolmesta ehdosta: missä kohde sijaitsee, onko LANilla paluureitti asiakasjoukkoon ja antaako yksi jaettu fyysinen linkki sen eristyksen, jonka väität. Vastaa noihin kolmeen, ja sovittimien määrä seuraa.

Kolme ehtoa, jotka sen ratkaisevat

Ensimmäinen ehto on kohde. VPN-isäntäkoneen omaan palveluun päästään vain tunneliliitännän kautta, kun taas LANissa oleva isäntä vaatii edelleenlähetystä ja paluureitin. Toinen ehto on tuo paluureitti, koska LAN-laitteen on tiedettävä, miten asiakasjoukkoon päästään, joko reitin tai palvelimella tehtävän käännöksen kautta.

Kolmas ehto on erottelu. Yksi sovitin tarkoittaa, että jokainen paketti, salattu tai ei, jakaa linkin ja yleensä käytäntöketjun, joten erilliseen laitteistoon nojaava eristysväite ei täyty yhdellä liitännällä. Se on tosiasia reitistä, ei siitä, miten käyttöjärjestelmä on määritetty. Voit yhä suodattaa tunnelin liikennettä, mutta et voi väittää rajaa, jota sinulla ei ole.

Mikään kolmesta ei koske kotelon porttien määrää. Ne koskevat reititystä, osoitteiden omistusta ja sitä, kuinka paljon rakenne nojaa fyysiseen erotteluun.

Kaksi sovitinta on edelleen perusteltu valinta, kun fyysiset vyöhykkeet, erilliset uplinkit, läpäisykyky tai kaistanulkoinen palautumisreitti sen oikeuttavat. Ne ovat konkreettisia vaatimuksia, ja ne kannattaa esittää ennen kuin kukaan tilaa laitteistoa.

Kun palvelu toimii VPN-isäntäkoneella

Yksinkertaisin tapaus ei tarvitse lainkaan edelleenlähetystä. Daemon vastaanottaa asiakkaan paketit tunneliliitännällä ja antaa ne paikalliselle pistokkeelle, ja vastaus palaa samaa liitäntää pitkin. Asiakasjoukon osoite on isäntäkoneen kannalta todellinen paikallinen osoite.

Kaksi asiaa on silti saatava oikein: palvelun on kuunneltava osoitteessa, johon tunneli pääsee, ja isäntäkoneen palomuurin on hyväksyttävä tunneliliitännälle saapuva liikenne. Molemmat näkyvät alla olevissa komennoissa.

ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1

Palvelun sitominen vain julkiseen osoitteeseen tai tunneliliitännän suodattaminen vahingossa tuottaa yhteyden, joka saavuttaa isäntäkoneen ja kuolee sitten. Se näyttää VPN-vialta ja on yleensä pistoke- tai palomuuripäätös.

Kun kohde sijaitsee LANissa

Tässä yhden sovittimen rakenne ansaitsee hankalan maineensa. Palvelimen on edelleenlähetettävä asiakkaan paketit kohti LANia, ja LAN-laitteen on lähetettävä vastaukset takaisin asiakasjoukkoon. Joko kannat joukon reittinä LANissa tai käännät lähdeosoitteen palvelimella, jotta vastaukset palaavat palvelimelle itselleen.

Molemmat vastaukset ovat perusteltuja, ja ne epäonnistuvat eri tavoin. Paluureitti pitää alkuperäisen asiakasosoitteen kohteen nähtävänä, mikä on hyvä lokeille ja huono palomuurisäännöille, jotka olettavat LAN-osoitteita. Käännös pitää LANin yksinkertaisena ja kätkee asiakkaan identiteetin kohteelta.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0

Epäsymmetrinen reitti on klassinen oire: asiakkaan pyyntö saapuu, vastaus lähtee toisen reitittimen kautta ja yhteys vanhenee ilman virhettä kummassakaan päässä. Kaappaa molemmilla puolilla ennen kuin päättelet tunnelista mitään.

Miksi alias ei luo toista vyöhykettä

Toisen osoitteen lisääminen samalle sovittimelle tai näennäisliitännän luominen toisen portin jäljittelemiseksi muuttaa hyvin vähän. Paketit lähtevät yhä samaa fyysistä linkkiä, samaa kytkinporttia ja yleensä samaa palomuuriketjua pitkin, joten niiden välillä ei ole uutta rajaa. Se on kokoonpanon mukavuus, ei segmentointi. Sen kohteleminen vyöhykerajana on tapa, jolla eristysväite säilyy vain paperilla.

Erillinen vyöhyke vaatii todellisen erottelun reitillä, ja sen toinen sovitin täyttää. Jos sääntö riippuu siitä, ettei VPN:ää kohti kulkeva liikenne koskaan jaa lähetysverkkotunnusta LANia kohti kulkevan liikenteen kanssa, yksi kaapeli ei voi tarjota sitä ominaisuutta, riippumatta siitä, miten isäntäkone on osoitettu.

Kun tuote dokumentoi moniliitäntäisen topologian tietylle tilalle, seuraa kyseisen tuotteen dokumentaatiota äläkä keksi kiertotietä. Valmistajat myös muuttavat tuettuja topologioitaan versioiden välillä, mikä on toinen syy lukea nykyistä opasta vanhan velhon kuvakaappauksen sijaan.

Tarkista rakenne sallimaasi liikennettä vasten

Listaa liikenneluokat, jotka palvelimen odotetaan kantavan: asiakkaasta isäntään, asiakkaasta LANiin, isännästä LANiin ja salattu ulkoinen yhteys. Jokaisella luokalla on lähde, kohde ja liitäntä, ja rakenteen on täytettävä kaikki neljä yhtä aikaa. Rakenne, joka selviää kolmesta, on yleensä se, joka tuottaa tikettejä.

Vahvista sitten todelliset liitännät ja todellinen kaappaus, ei suunnitteludokumentin kaaviota. Alla olevat komennot tulostavat molemmat näkymät.

ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5

Jos ulkoinen kaappaus näyttää salatun liikenteen ja sisäinen kaappaus näyttää puretun liikenteen tunneliliitännällä samalla kun fyysinen sovitin kantaa molempia, yksi NIC hoitaa työn. Jos sisäinen kaappaus on tyhjä, ongelma on tunnelissa tai edelleenlähetyssäännöissä, ei sovittimien määrässä. Ratkaise topologia noista kahdesta kaappauksesta ja reititystaulukosta, niin seuraavalla muutoksella on jotain mitä vasten mitata.