Wêrom’t Access Server-klanten net berikber binne fanút it LAN

Rûte klanten hâlde har pooladres, dus antwurden hawwe in weromrûte nedich. Lês de boarne by de tsjinst, en foegje dan de poolrûte ta op de juste gateway.

De laptop makket ferbining, de tunnel is omheech, en oanfragen nei in ynterne tsjinst hingje by it ferbinen. Op ’e tsjinst sels komt de oanfrage fan in adres lykas 10.90.0.25, it antwurd giet fuort nei de standertgateway, en der komt neat werom, om’t dy gateway gjin idee hat wêr’t 10.90.0.25 wennet. Fan ’e oare kant liket deselde flater op in ynterne host dy’t in ferbûne klant net pingje kin. Beide binne ien ûntbrekkend objekt: in weromrûte nei de VPN-klantpool, dy’t allinne it priveenetwurk tafoegje kin.

Lês it boarneadres dat de tsjinst sjocht

Dat iene fjild beslút al it oare. As de ynterne tsjinst it pooladres sjocht, rûtet Access Server ynstee fan klantferkear te ferbergjen, en elk antwurd moat werom nei de pool rûte wurde. As it ynstee it eigen privee-adres fan ’e server sjocht, maskearret de server en wurket it antwurdpaad al, mar tsjin de priis fan it ferlies fan alle identiteit per klant yn ’e logs en tagongsregels fan ’e tsjinst.

Fergelykje beide einen foardat jo wat feroarje. Op ’e server, list de tunnelinterfaces en har adressen op; op ’e klant, befêstigje hokker fan dy adressen it echt hat; op ’e ynterne host, sjoch nei in libbene ferbining.

ip -br addr show
ss -tnp state established '( dport = :443 )'
ip route get 10.90.0.25

It lêste kommando is it iene dat mislearret yn ’e brutsen sitewaasje: it meldt itsij it tunnelprefix as net berikber, itsij, slimmer, jout jo standertgateway werom, en sa einigje antwurden op it ynternet.

Tink net dat der mar ien pool is. In server kin in dynamysk berik hawwe plus statyske taskriuwings per brûker, en it statyske adres kin hielendal bûten it dynamyske prefix lizze. As jo allinne it berik rûte dat jo ûnthâlde, bliuwe brûkers mei fêste adressen brutsen en alle oaren melde it probleem as oplost.

Foegje de rûte ta dêr’t it antwurd besletten wurdt

De rûte heart op ’e gateway dy’t de ynterne tsjinst al brûkt, net op ’e tsjinst, útsein as dy syn eigen ferkear rûtet. Wys it nei it berikbere privee-adres fan Access Server, dat in oare wearde is as it tunneladres dat in klant hat.

ip route add 10.90.0.0/24 via 10.0.1.5
ip route get 10.90.0.25

Yn in wolknetwurk wurdt deselde bewearing in yngong yn ’e rûtetabel wêrfan it doel de ynstânsje of netwurkinterface is dêr’t de server op draait, mei boarne- en bestimmingskontrôle útskeakele op dy interface. Tink derom wat dy yngong net docht: in rûte is gjin tagongsjefte, dus feiligensgroepen, netwurk-ACL’s en de hostfirewall moatte it ferkear noch tastean.

Meitsje it duorsum, en hâld de poolgrutte earlik. Twa net-oanswolige pools hawwe twa rûtes nedich, en in pool dy’t foarby syn konfigurearre prefix groeit, produsearret stilwei klanten waans antwurden nearne hinne kinne. As jo de poolberikken beheare, kies in gearfetting dy’t jo ien kear rûte kinne en dan gewurde litte.

Trochstjoering en filters moatte mei de rûte oerienkomme

Rûten is mar de helte fan ’e wei. De server moat tastien wurde om troch te stjoeren tusken de tunnel en de privee-interface, wat op Linux net.ipv4.ip_forward betsjut plus in trochstjoerkeatling dy’t it pear interfaces tastiet, en op in hurde host meastentiids in eksplisite regel foar elke rjochting.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A5 forward

Steatfilters ferklearje in symptoom dat minsken op it ferkearde paad stjoert. In antwurd binnen in fêstige stream hat gjin nije ynkommende regel nedich, dus in ferbining dy’t nei de SYN-ACK hinget, wurdt net blokkearre troch in ûntbrekkende akseptregel; it wurdt weilitten of ferkeard rûte. Hâld dat ûnderskied, want it skiedt in rûteferoaring fan in firewallferoaring.

Asymmetryske weromwegen binne de stillere ferzje fan itselde probleem. As twa rûtes de pool berikke en it antwurd nimt dyjinge dy’t fan in oare interface fuortgiet as dêr’t de oanfrage op oankaam, smyt strang werompaadfiltering it fuort en mislearret de stream allinne foar guon klanten.

Rûte of maskearre: kies bewust

Rûte modus bewarret it pooladres fan ’e klant by de tsjinst, wat logging en belied per klant mooglik makket, en as ruil hat elk yntern netwurk dat in klant beäntwurdzje moat de poolrûte nedich. Maskearre modus hellet dy eask fuort om’t antwurden weromgeane nei de server, mar de tsjinst kin no ien klant net mear fan in oare ûnderskiede en kin neat nei in spesifike klant ta begjinne.

Dat gedrach feroarje op in libbene server smyt besteande sessys fuort, dus test earst mei ien klant en ien stream. As de omskeakeling it juste antwurd is, is it in konfiguraasjebeslút op ’e server, net wat jo omrinne troch rûtes ta te foegjen dy’t oerstallich wurde.

In subnet efter de klant is in aparte taak

In apparaat berikke op it eigen LAN fan ’e laptop is net itselde as it tunneladres fan ’e laptop berikke. It easket dat de klant as subnetgateway fungearret: in oanjûn netwurk oan ’e klantkant, trochstjoering oan yn it bestjoeringssysteem fan ’e klant, en in rûte yn dat LAN werom nei de klant. In priveenetwurkrûte tafoegje foar it thúsberik fan ’e laptop docht dit net, en it skept konflikten as twa brûkers itselde thúsberik hawwe.

Rjochting is ek in beliedsfraach. Tastimming foar in klant om in ferbining nei in ynterne tsjinst te iepenjen jout in ynterne host net automatysk it rjocht om in ferbining nei dy klant te iepenjen. Kontrolearje it tagongsbelied fan ’e server en de hostfirewall fan ’e klant foardat jo konkludearje dat it paad brutsen is.

Kontrolearje mei ien stream en ien opname

Bewiis it paad mei ien ferbining ynstee fan in algemiene berikberheidstest. Besjoch deselde stream oan beide einen: de oanfrage dy’t by de tsjinst oankomt en it antwurd dat dy ferlit.

tcpdump -ni any host 10.90.0.25 and port 443

Foar de repaasje lit de opname it antwurd fuortgean sjen nei in gateway dy’t it net rûte sil. Nei de repaasje giet it antwurd nei de server en wurdt de stream foltôge. Befêstigje dan de rûte dy’t de gateway brûke soe foar in twadde klantadres, sadat in pool dy’t jo net dekt hawwe no opkomt en net oer in wike.

Einigje mei de fjouwer kontrôles dy’t dit slute: it boarneadres by de tsjinst komt oerien mei de modus dy’t jo bedoelden, de gateway hat in rûte nei elke pool yn gebrûk, trochstjoering en filters tastean beide rjochtingen, en ien echte stream foltôget fan begjin oant ein. Faak stelde fragen oer Access Server-rûten stelt itselde prinsipe foar de ynstalleare ferzje, waans stipe konfiguraasje-interface fan âldere hantliedingen ferskille kin.

Relatearre artikelen