Üks NIC või kaks? Kuidas otsustada VPN-serveri liideste paigutuse üle

Üks füüsiline adapter on paljude VPN-serverite jaoks piisav ja see pole ka universaalne lahendus. Krüpteeritud ühendus saabub sellele adapterile, VPN-protsess dekrüpteerib selle ja sisemine liiklus väljub virtuaalse liidese kaudu enne, kui jõuab kohaliku teenuseni või marsruuditud LAN-ini. Kas see töötab, sõltub kolmest tingimusest: kus sihtkoht asub, kas LAN-il on tagasitee kliendikogumisse ja kas üks jagatud füüsiline link annab teile selle isolatsiooni, mida väidate. Vastake neile kolmele ja adapterite arv järgneb.

Kolm tingimust, mis selle otsustavad

Esimene tingimus on sihtkoht. Teenus VPN-hostil endal on kättesaadav ainult tunneli liidese kaudu, samas kui LAN-is asuv host nõuab edastamist ja tagasiteed. Teine tingimus on see tagasitee, sest LAN-seade peab teadma, kuidas kliendikogumisse jõuda, kas marsruudi või serveris toimuva tõlkimise kaudu.

Kolmas tingimus on eraldamine. Üks adapter tähendab, et iga pakett, krüpteeritud või mitte, jagab linki ja tavaliselt poliitikaahelat, seega isolatsiooniväidet, mis sõltub eraldi riistvarast, üks liides ei täida. See on fakt tee kohta, mitte selle kohta, kuidas operatsioonisüsteem on seadistatud. Saate tunneliliiklust endiselt filtreerida, kuid ei saa väita piiri, mida teil pole.

Ükski neist kolmest ei käsitle korpuse portide arvu. Need käsitlevad marsruutimist, aadresside omamist ja seda, kui palju sõltub lahendus füüsilisest eraldamisest.

Kaks adapterit jäävad õigustatud valikuks, kui füüsilised tsoonid, eraldi uplink-ühendused, läbilaskevõime või ribaväline taastetee seda õigustavad. Need on konkreetsed nõuded ja neid tasub välja öelda enne, kui keegi riistvara tellib.

Kui teenus töötab VPN-hostil

Kõige lihtsam juhtum ei vaja üldse edastamist. Deemon võtab kliendi paketid vastu tunneli liidesel ja annab need kohalikule soklile ning vastus tuleb sama liidese kaudu tagasi. Kliendikogumi aadress on hosti seisukohast tõeline kohalik aadress.

Kaks asja peavad siiski õiged olema: teenus peab kuulama aadressil, mille tunnel suudab kätte saada, ja hosti tulemüür peab vastu võtma tunneli liidesele saabuva liikluse. Mõlemad on allolevates käskudes näha.

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

Teenuse sidumine ainult avaliku aadressiga või tunneli liidese ekslik filtreerimine tekitab ühenduse, mis jõuab hostini ja sureb seejärel. See näeb välja nagu VPN-i rike ja on tavaliselt sokli või tulemüüri otsus.

Kui sihtkoht asub LAN-is

Siin teenib ühe adapteri lahendus välja oma maine tülikana. Server peab edastama kliendi paketid LAN-i suunas ja LAN-seade peab saatma vastused tagasi kliendikogumisse. Kas kannate selle kogumi LAN-is marsruudina või tõlgite lähteaadressi serveris, et vastused tuleksid tagasi serverisse endasse.

Mõlemad vastused on õigustatud ja need ebaõnnestuvad erinevalt. Tagasitee marsruut hoiab algse kliendi aadressi sihtkohale nähtavana, mis on hea logide ja halb LAN-aadresse eeldavate tulemüürireeglite jaoks. Tõlkimine hoiab LAN-i lihtsana ja peidab kliendi identiteedi sihtkoha eest.

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

Asümmeetriline tee on klassikaline sümptom: kliendi päring saabub, vastus väljub teise ruuteri kaudu ja ühendus aegub ilma veata kummaski otsas. Jälgige mõlemal pool, enne kui tunnelist midagi järeldate.

Miks alias ei loo teist tsooni

Teise aadressi lisamine samale adapterile või teise pordi jäljendamiseks näilise liidese loomine muudab väga vähe. Paketid väljuvad endiselt sama füüsilise lingi, sama kommutaatoripordi ja tavaliselt sama tulemüüriahela kaudu, seega nende vahel pole uut piiri. See on seadistamise mugavus, mitte segmenteerimine. Selle käsitlemine tsoonipiirina on viis, kuidas isolatsiooniväide jääb püsima ainult paberil.

Eraldi tsoon vajab tões tõelist eraldamist ja see on nõue, mille teine adapter täidab. Kui reegel sõltub sellest, et VPN-i poole suunatud liiklus ei jagaks kunagi leviedastusdomeeni LAN-i poole suunatud liiklusega, ei suuda üks kaabel seda omadust pakkuda, ükskõik kuidas host on adresseeritud.

Kui toode dokumenteerib konkreetse režiimi jaoks mitme liidese topoloogiat, järgige selle toote dokumentatsiooni, mitte ärge mõelge välja möödaviisi. Tootjad muudavad ka toetatud topoloogiaid versioonide vahel, mis on veel üks põhjus lugeda praegust juhendit, mitte vana viisardi ekraanipilti.

Kontrollige paigutust lubatava liikluse vastu

Loetlege liiklusklassid, mida server peaks kandma: klient hostini, klient LAN-ini, host LAN-ini ja krüpteeritud väline ühendus. Igal klassil on allikas, sihtkoht ja liides ning paigutus peab täitma kõiki nelja korraga. Lahendus, mis tuleb toime kolmega, on tavaliselt see, mis tekitab pileteid.

Seejärel kinnitage tegelikud liidesed ja tegelik püüdmine, mitte projekteerimisdokumendi skeem. Allolevad käsud trükivad mõlemad vaated.

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

Kui väline püüdmine näitab krüpteeritud liiklust ja sisemine püüdmine näitab dekrüpteeritud liiklust tunneli liidesel, samal ajal kui füüsiline adapter kannab mõlemat, teeb üks NIC töö ära. Kui sisemine püüdmine on tühi, on probleem tunnelis või edastusreeglites, mitte adapterite arvus. Otsustage topoloogia nende kahe püüdmise ja marsruutimistabeli põhjal ning järgmisel muudatusel on millega mõõta.